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!
Cookies zijn kleine tekstbestanden die door websites kunnen worden gebruikt om gebruikerservaringen efficiënter te maken.
Volgens de wet mogen wij cookies op uw apparaat opslaan als ze strikt noodzakelijk zijn voor het gebruik van de site. Voor alle andere soorten cookies hebben we uw toestemming nodig.
Deze website maakt gebruik van verschillende soorten cookies. Sommige cookies worden geplaatst door diensten van derden die op onze pagina’s worden weergegeven.
Via de cookieverklaring op onze website kunt u uw toestemming op elk moment wijzigen of intrekken.
In ons privacybeleid vindt u meer informatie over wie we zijn, hoe u contact met ons kunt opnemen en hoe we persoonlijke gegevens verwerken.
Strikt noodzakelijk
Strikt Noodzakelijke Cookie moet te allen tijde worden ingeschakeld, zodat we uw voorkeuren voor cookie-instellingen kunnen opslaan.
Cookie naam
Beschrijving
Duur
pll_language
Deze cookie wordt gebruikt om de taal van de website te bepalen.
1 jaar
cookiesession1
cookiessession1 wordt gebruikt om een optimale website-ervaring te bieden door middel van de volgende items:
- Network equipment failover session persistence;
- client tracking;
- Logging aggregation to a client;
- Security features such as DOS protection;
- Session timeout.
1 jaar
moove_gdpr_popup
Deze cookie wordt gebruikt om de cookie voorkeuren op te slaan
1 jaar
Google Analytics
Cookie naam
Beschrijving
Duur
_ga
Wordt gebruikt om gebruikers te onderscheiden.
2 jaar
_gid
Wordt gebruikt om gebruikers te onderscheiden.
24 uur
_gat
Wordt gebruikt om de aanvraagsnelheid te vertragen. Als Google Analytics wordt geïmplementeerd via Google Tag Manager, krijgt deze cookie de naam _dc_gtm_<property-id>.
1 minuut
AMP_TOKEN
Bevat een token dat kan worden gebruikt om een klant-ID op te halen bij de AMP-client-ID-service. Andere mogelijke waarden duiden op opt-out, verzoek aan boord of een fout bij het ophalen van een klant-ID van de AMP-client-ID-service.
30 seconden tot 1 jaar
_gac_<property-id>
Bevat campagnegerelateerde informatie voor de gebruiker. Als u uw Google Analytics- en Google Ads-accounts heeft gekoppeld, zullen Google Ads-websiteconversietags deze cookie lezen, tenzij u zich afmeldt. Kom meer te weten.
90 dagen
_gcl_au
Gebruikt door Google AdSense om te experimenteren met de efficiëntie van advertenties op websites die hun services gebruiken.
3 maanden
CPSESSIONID
Gebruikt voor analyse van websitegebruik om gebruikerssessies te onderscheiden.
30 minuten
CPUSERID
Gebruikt voor analyse van websitegebruik en personalisatie om gebruikers te onderscheiden.
900 dagen
CPSESSIONEXP
Gebruikt voor analyse van websitegebruik en personalisatie om gebruikers te onderscheiden.
30 minuten
Marketing
De volgende marketing cookies worden gebruikt:
Hotjar
Cookie naam
Beschrijving
Duur
_hjClosedSurveyInvites
Deze cookie wordt geplaatst zodra een bezoeker interageert met een pop-upvenster met een enquête-uitnodiging. Het wordt gebruikt om ervoor te zorgen dat dezelfde uitnodiging niet opnieuw verschijnt als deze al is getoond.
1 jaar
_hjDonePolls
Deze cookie wordt geplaatst zodra een bezoeker een peiling voltooit met behulp van de Feedback Poll-widget. Het wordt gebruikt om ervoor te zorgen dat dezelfde peiling niet opnieuw verschijnt als deze al is ingevuld.
1 jaar
_hjMinimizedPolls
Deze cookie wordt geplaatst zodra een bezoeker een Feedback Poll-widget minimaliseert. Het wordt gebruikt om ervoor te zorgen dat de widget geminimaliseerd blijft wanneer de bezoeker door uw site navigeert.
1 jaar
_hjDoneTestersWidgets
Deze cookie wordt ingesteld zodra een bezoeker zijn informatie invoert in de widget Recruit User Testers. Het wordt gebruikt om ervoor te zorgen dat hetzelfde formulier niet opnieuw verschijnt als het al is ingevuld.
1 jaar
_hjMinimizedTestersWidgets
Deze cookie wordt geplaatst zodra een bezoeker een Recruit User Testers-widget minimaliseert. Het wordt gebruikt om ervoor te zorgen dat de widget geminimaliseerd blijft wanneer de bezoeker door uw site navigeert.
1 jaar
_hjDoneSurveys
Deze cookie wordt geplaatst zodra een bezoeker een enquête invult. Het wordt gebruikt om de inhoud van de enquête alleen te laden als de bezoeker de enquête nog niet heeft ingevuld.
1 jaar
_hjIncludedInSample
Deze cookie wordt geplaatst om Hotjar te laten weten of die bezoeker is opgenomen in de steekproef die wordt gebruikt om Heatmaps, Funnels, Recordings, etc. te genereren.
1 jaar
_hjShownFeedbackMessage
Deze cookie wordt geplaatst wanneer een bezoeker Inkomende Feedback minimaliseert of voltooit. Dit wordt gedaan zodat de inkomende feedback onmiddellijk als geminimaliseerd wordt geladen als ze naar een andere pagina navigeren waar deze is ingesteld om te worden weergegeven.
1 jaar
Onlinesucces.nl
Cookie naam
Beschrijving
Duur
logger
connect.onlinesucces.nl
365 days
Facebook
Naam
Doel
Vervaldatum
fr
Gebruikt door Facebook om een reeks advertentieproducten te leveren, zoals realtime bieden van externe adverteerders.
3 maanden
fbp
Gebruikt door Facebook om advertenties te leveren. De cookie bevat een versleutelde Facebook-gebruikers-ID en browser-ID. Het zal informatie van deze website ontvangen om advertenties beter af te stemmen en te optimaliseren.
3 maanden
Linkedin
Naam
Doel
Vervaldatum
ln_or
Gebruikt om te bepalen of analyse van Oribi kan worden uitgevoerd op een specifiek domein
1 dag
Schakel eerst strikt noodzakelijke cookies in om uw voorkeuren op te slaan!