Je kunt Scrummen wat je wilt, maar zonder goede specificaties wordt het nooit een succes.
Om tot goede input voor het development-team te komen heb je het volgende nodig:
- een goed refinement-proces;
- een gestructureerde, compacte en volledige notatiewijze;
- een goede inschattingen.
Deze blogpost zal over het proces gaan. In de Scrum Guide wordt als eenheid voor de requirements het Product Backlog Item genoemd, een vrij algemene benaming. In de praktijk kom je vaak het begrip User Story tegen, welke een goede kapstok vormt om de requirements mee in te delen.
‘Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. (Scrum Guide, 2016)’
Product Backlog refinement
Product Backlog refinement, of kortweg refinement, vult het gat tussen ‘the business’ en de developers: een stukje glad ijs. Het doel van de refinement is om de product backlog te voorzien van genoeg goed gespecificeerde user stories, zodat het Scrum team tenminste de volgende sprint met user stories kan vullen. Werk met het refinen niet te ver vooruit, want het risico bestaat dat bepaalde user stories – in verband met wijzigende prioriteiten – komen te vervallen: zonde van de tijd. Probeer voor zo’n 1,5 tot 2 sprints voorraad te hebben.
‘Het gat tussen de business en de developers: een stukje glad ijs’
Het is voor refinements aan te bevelen om een ritme aan te houden dat op vaste, constante momenten in de sprint valt. Houdt de refinements zo vaak als nodig is en laat de sessies niet te lang duren, zodat iedereen scherp blijft. Liever vier keer een uur dan één keer vier uur. Bij een startend project zal waarschijnlijk meer tijd nodig zijn dan bij een al langer lopend project.
The R-team
Als ik het over het refinement-team heb, dan bedoel ik het team dat de specificaties vastlegt. Voor grotere teams is het niet nodig om het gehele Scrum-team aanwezig te laten zijn bij het definiëren van de specificaties. Dat kan, zeker met een startend team, tot onnodige discussies leiden, wat tijd kost. Tijdens het inschatten is juist het gehele Scrum-team nodig en zijn specialisten van buiten het team niet nodig of zelfs niet gewenst. In de praktijk heb ik gemerkt dat het goed werkt om de requirement- en pokersessies te scheiden.
Om een parallel te trekken: stel elke dag is een sprint en voor ons ‘gezinsteam’ bestaat de user story ‘Diner’. Als we thuis gaan eten, gaan we niet het z’n allen in overleg over hoe die maaltijd er precies uit moet zien: dat zou een discussie worden waarbij er altijd iemand verliest. Wij als ouders kunnen prima beslissen hoe de user story ingevuld moet worden. Voor de uiteindelijke inschatting hebben we de input van de kinderen wel nodig: zij weten of ze veel honger hebben, of dat ze wellicht bij een vriendje mee willen eten.
Tijdens de refinement zijn een aantal rollen vertegenwoordigd:
– de Product Owner als vertegenwoordiger van de business en leider van de sessies. Zorgt voor de te behandelen user stories.
– één of twee vertegenwoordigers van het development team, omdat deze het beste op de hoogte zijn van de (technische) stand van zaken en omdat zij in kunnen schatten of er bijvoorbeeld componenten zelf gebouwd, beter aangekocht of hergebruikt kunnen worden.
– de enterprise en/of solutions architect dient in elk geval aanwezig te zijn als user stories worden behandeld die nieuwe componenten bevatten of als wijzigingen in de architectuur of infrastructuur worden behandeld.
– afhankelijk van het soort oplossing zouden bijvoorbeeld ook UX- en/of UI-designers, UI-developers of andere experts vanuit de business aan kunnen sluiten.
Afhankelijk van de behandelde user stories kunnen deze vertegenwoordigers wisselen. Continuïteit en kwaliteit dienen echter geborgd te worden en zeker in het begin van een project is het project meer gebaat bij een vast team dat in de flow van het refinen kan komen. De oplettende lezer ziet dat er geen aparte rol van analist is. Dat klopt: het Scrum-team is ‘cross functional’ en kan prima zelf de requirements vaststellen. Daarmee valt er een laag weg, wat de efficiëntie ten goede komt.
Het R-team: het team dat de specificaties vastlegt
Statussen
User stories doorlopen verschillende statussen voordat deze door het development-team opgepakt kunnen worden:
– New
– Refinement
– Poker (of Estimate, afhankelijk van de gekozen methode. In deze blog houd ik Poker aan)
– Ready
Een user story wordt door de Product Owner met de status New aangemaakt. Zodra deze de basisfunctionaliteit als user story beschreven heeft, wordt de status op Refinement gezet en kan het door het refinement-team opgepakt worden.
Nu kunnen user stories volledig tijdens de refinements worden uitgewerkt, maar het is veel efficiënter als één of twee van de refiners de user stories voor elke refinement voorbereiden. Deze stap van voorbereiding kan eventueel als aparte status in het proces worden toegevoegd, maar de stap is niet vereist om te kunnen refinen.
Tijdens de refinements zullen vaak nog specificaties aangevuld of gewijzigd worden. Laat degene die de afgesproken notatiewijze beheerst aan het toetsenbord zitten. Hij/zij schrijft de specificaties direct en veel sneller in de juiste opmaak. Dat scheelt tijd en ongemakkelijke situaties.
Zodra een user story is uitgewerkt en geen openstaande acties meer heeft, dan kan de status op Poker worden gezet. In deze fase zal het development-team de complexiteit van de user story inschatten volgens de effectieve Planning Poker methode. De daaropvolgende en tevens laatste status is Ready: de user story is gereed om door het development-team in één van de volgende sprints opgepakt te worden.
Overzicht
In een systeem als VSTS en TFS kunnen eenvoudig overzichten gemaakt worden die op status en/of tags kunnen filteren. Maak hier zeker gebruik van, het maakt de refinements en poker-sessies erg overzichtelijk en voorkomt het zoeken van die ene user story terwijl er negen man zitten te wachten.
Samengevat
Het refinement-team kan het beste compact zijn om discussies te voorkomen. De refinements zouden vooral moeten dienen om voorbereide user stories te reviewen. Het refinement-proces kent de statussen New, Refinement, Poker en Ready. Maak overzichten op basis van de statussen en tags!
Tot slot en zeer belangrijk: zorg dat er een onderling afgesproken notatiewijze is en dat tenminste één, maar liever meer teamleden zich deze notatiewijze eigen hebben gemaakt. Meer daarover in de volgende post!
