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 noodzakelijke cookies
Strikt Noodzakelijke Cookie moet te allen tijde worden ingeschakeld, zodat we uw voorkeuren voor cookie-instellingen kunnen opslaan.
Analytische cookies
Analytische cookies meten websitebezoek, waarmee de eigenaar zijn website kan verbeteren. Denk aan het aantal bezoekers en de meest bezochte webpagina’s.
Google Analytics
_ga
2 years
Used to distinguish users.
_gid
24 hours
Used to distinguish users.
_gat
1 minute
Used to throttle request rate. If Google Analytics is deployed via Google Tag Manager, this cookie will be named _dc_gtm_<property-id>.
AMP_TOKEN
30 seconds to 1 year
Contains a token that can be used to retrieve a Client ID from AMP Client ID service. Other possible values indicate opt-out, inflight request or an error retrieving a Client ID from AMP Client ID service.
_gac_<property-id>
90 days
Contains campaign related information for the user. If you have linked your Google Analytics and Google Ads accounts, Google Ads website conversion tags will read this cookie unless you opt-out. Learn more.
Schakel eerst strikt noodzakelijke cookies in om uw voorkeuren op te slaan!
Marketing
De volgende marketing cookies worden gebruikt:
Hotjar
Cookie naam
Beschrijving
Duur
_hjClosedSurveyInvites
This cookie is set once a visitor interacts with a Survey invitation modal pop-up. It is used to ensure that the same invite does not re-appear if it has already been shown.
365 days
_hjDonePolls
This cookie is set once a visitor completes a Poll using the Feedback Poll widget. It is used to ensure that the same Poll does not re-appear if it has already been filled in.
365 days
_hjMinimizedPolls
This cookie is set once a visitor minimizes a Feedback Poll widget. It is used to ensure that the widget stays minimized when the visitor navigates through your site.
365 days
_hjDoneTestersWidgets
This cookie is set once a visitor submits their information in the Recruit User Testers widget. It is used to ensure that the same form does not re-appear if it has already been filled in.
365 days
_hjMinimizedTestersWidgets
This cookie is set once a visitor minimizes a Recruit User Testers widget. It is used to ensure that the widget stays minimized when the visitor navigates through your site.
365 days
_hjDoneSurveys
This cookie is set once a visitor completes a survey. It is used to only load the survey content if the visitor hasn't completed the survey yet.
365 days
_hjIncludedInSample
This cookie is set to let Hotjar know whether that visitor is included in the sample which is used to generate Heatmaps, Funnels, Recordings, etc.
365 days
_hjShownFeedbackMessage
This cookie is set when a visitor minimizes or completes Incoming Feedback. This is done so that the Incoming Feedback will load as minimized immediately if they navigate to another page where it is set to show.
365 days
Onlinesucces.nl
Cookie naam
Beschrijving
Duur
logger
connect.onlinesucces.nl
365 days
Facebook
Naam
Aanbieder
Doel
Vervaldatum
fr
http://facebook.com/
Used by Facebook to deliver a series of advertisement products such as real time bidding from third party advertisers.
3 months
ilionx.com analytics
Naam
Aanbieder
Doel
Vervaldatum
CPSESSIONID
http://www.ilionx.com/
Used for website usage analytics to distinguish user sessions.
30 minutes
CPUSERID
http://www.ilionx.com/
Used for website usage analytics and personalization to distinguish users.
900 days
Schakel eerst strikt noodzakelijke cookies in om uw voorkeuren op te slaan!