Nu kan je denken: dat heet toch product backlog refinement? Je wordt er als Scrumteam bij betrokken. En aan het eind snap je de story, begrijp je de prioriteit en sta je er dus volledig achter. Voldoende toch? Tja, ik zie zelf in de backlog refinement vaak beïnvloed worden door twee factoren:
Het eerste is de expertfactor. De productowner is expert op het gebied van de business. Wat de productowner zegt, stel je niet vaak ter discussie. En dat moet je als basis ook niet willen. Ik heb regelmatig meegemaakt dat een productowner vijf keer opnieuw de discussie aan moet gaan waarom een medewerker in het bedrijf echt wel blij wordt van een bepaalde story, zoals die beschreven is. Dat gaat vaak te ver, je moet het vertrouwen hebben dat de productowner met de persoon heeft gesproken. En het gewenste doel goed kan weergeven. Maar zomaar geloven wat de productowner qua businesseisen in de story zet, dat is toch een ander verhaal. Een productowner is misschien wel expert, maar geen allesweter. En is net als iedereen een mens, die fouten maakt.
De tweede factor is de uitzonderingsfactor. Elk Scrumteam heeft regels en afspraken gemaakt. En op het moment van opstellen staat iedereen hierachter. Maar dan verloopt de tijd. Een teamlid had wat tijd te weinig, er is een crisis die om snelle refinement vraagt of je hebt het gevoel dat de gemaakte afspraak nu vooral tijdsverspilling is. Dan ga je een uitzondering maken. Voor deze story verbreek je de afspraak. Daarna voor alle soortgelijke story's, want je deed het bij die ene story ook. Vervolgens voeg je hier een uitzonderingsgroep aan toe, want dat kon bij de vorige groep ook. En voor je het weet, is de afspraak eerder uitzondering dan regel.
Om dit te voorkomen moet je leren om zelf en op je eigen moment de backlog de testen. Ik spreek bewust niet van review, maar van testen. Bij een review speelt persoonlijke kennis en mening een belangrijke rol. Maar dat deel kan je vaak bij de refinement wel oppakken. Bij testen leg je het gemaakte product naast een bepaald eisenpakket. En kijkt of het product eraan voldoet. Vaak op eigen gelegenheid, zodat je er goed te tijd voor kan nemen.
Het projectdoel
Elk project heeft een doel. En het doel is vaak perfect geschreven voor de managers, die het geld beschikbaar moeten maken. Vaak ook nog voldoende om het Scrumteam en andere mensen in grote lijnen in te lichten. Maar kan je als Scrumteam het projectdoel ook gebruiken om de story en de backlog te testen? Anders gezegd: zorg ervoor dat iedereen in het Scrumteam het projectdoel begrijpt.
Waarom? Stel dat de organisatie het belangrijk vindt dat op basis van gebruikersstatistieken achterhaald kan worden wat wel en niet werkt. Dan kan het verstandig zijn om bij elke story de volgende vraag te stellen: welke handelingen moeten gemeten kunnen worden? En kan dit meteen in deze story of moet dit in een aparte story er vlak achteraa?. Ook qua prioriteit kan het verschil uitmaken. Zijn alle onderdelen eigenlijk al te meten? Zo nee, moeten de story's die dit gaan oplossen, dan niet snel opgepakt worden?
Besef dat de hier beschreven business-eis niet snel op papier wordt gezet. Hij wordt als logisch gezien. En voor management en introductiemeetings niet zo van belang. Zorg daarom dat je duidelijkheid hebt over onderdelen als onderhoudbaarheid, meetbaarheid, performance, security en foutvindbaarheid (logfiles, etc.). Weet welke van deze eisen voor de business het belangrijkste zijn, want dan weet je wat bij de story's en de backlogprioriteit ook het belangrijkste is. Daarnaast kan je zelf kijken of er nog story's missen om deze doelen te halen.
De afspraakstatistieken
Elke uitzondering los lijkt niet erg. Tenslotte is Scrum bedoelt om flexibel te zijn. Een keer op het laatste moment een story oppakken, moet kunnen. Dus als je dan een keer niet helemaal aan de regels voldoet, is Scrum daar vast voor. Het is in ieder geval wat ik vaak gehoord heb: ja maar, bij Scrum mag je de prioriteiten toch steeds wijzigen? Ja, dat mag. En ja, je mag ook uitzonderingen maken. Maar als dit verbloemt dat een organisatie slecht kan prioriteren en daarom van het ene 'het moet nu' naar het andere 'het moet nu' springt. Waardoor steeds opnieuw story's vanuit het niets bovenaan de backlog komen. Dan wordt deze Scrumregel misbruikt. En een ander voorbeeld: als het Scrumteam geen tijd heeft of zin heeft zich aan hun eigen afspraken te houden. En daarom steeds opnieuw een uitzondering afspreekt. Dan misbruik je de geboden flexibiliteit vooral om jezelf voor de gek te houden.
Het belangrijkste middel hiertegen: maak de uitzonderingen zichtbaar. Dit kost tijd, tijd die je misschien liever ergens anders aan zou besteden. Maar zeker in een tijd met veel neiging tot uitzonderingen, levert het uiteindelijk veel op. De afspraken zijn tenslotte niet voor niets gemaakt.
Zo heeft bijna elk Scrumteam wel eisen waaraan een story moet voldoen. Leg van de story's die door het team 'geschikt voor in de sprint' verklaard zijn, vast hoeveel story's ook werkelijk aan deze eisen voldoen. Neem van mij aan: als je ziet dat slechts 50% van je story's voldoet aan alle gemaakte afspraken, is het woord "uitzondering" plotseling moeilijker te gebruiken.
En zulke statistieken kan je ook gebruiken voor andere afgesproken mijlpalen met eisen, Zelf heb ik naast bovenstaande mijlpaal, ook wel eens gebruik gemaakt van de mijlpaal 'geschikt voor refinement'. Hierbij ga ik ervan uit dat alle story's die in de komende drie sprints zullen komen op basis van huidige prioriteit, aan de eisen voldoen die het Scrumteam heeft opgesteld om er storypoints aan toe te kennen. Hiervoor heb ik het gemiddelde aantal story's per sprint bepaalt en vervolgens met drie vermenigvuldigd.
Tenslotte
Leg dus je backlog en story's naast het testdoel. Bekijk statistisch of je uitzondering wel een uitzondering blijft. En zoek je eigen testen. Welke problemen loopt jouw organisatie tegen aan? Heb je genoeg kennis om zelf deze problemen bij backlog of story's aan te geven? Kan je deze problemen met statistieken inzichtelijk maken? Of kan je zelfs een hele andere oplossing vinden? Waar het om gaat, is dat je leert om problemen te voorkomen door gebruik te maken van eisen van de business en afspraken van het Scrumteam. Dit zorgt voor draagvlak en voorkomt dat je strijd als 'eenmansoorlog' wordt gezien. Veel succes!
