3. De backlog vullen en prioriteren
Een backlog is niet hetzelfde als een takenlijst. Op een takenlijst staat alles wat iemand ooit heeft geroepen, in de volgorde waarin het geroepen werd. In een Product Backlog staat hetzelfde werk, maar dan beschreven vanuit de gebruiker en op volgorde van belang. Dat verschil, van wat er gevraagd is naar wat het oplevert en wat eerst moet, is het werk van dit hoofdstuk.
After this chapter:
- Kun je een user story schrijven in het formaat Als, wil ik, zodat.
- Ken je de drie C's en weet je waarom het kaartje niet het belangrijkste is.
- Kun je een story toetsen aan de zes INVEST-criteria.
- Weet je wat backlog refinement is en wanneer je het doet.
- Ken je de vier MoSCoW-categorieën en de 60-20-20-verdeling.
De user story
De meest gebruikte vorm voor een backlog-item is de user story: een korte beschrijving van een wens vanuit het perspectief van de eindgebruiker. Geen technische specificatie en geen functionele eis van twee pagina's, maar een zin die uitnodigt tot gesprek. De klassieke vorm ligt vast:
Als <rol> wil ik <functionaliteit> zodat <waarde>.
Die structuur dwingt je om drie vragen te beantwoorden. Als zegt voor wie je dit doet. Wil ik zegt wat het moet kunnen. Zodat zegt wat het oplevert. Vooral dat laatste stuk is goud waard. Zonder duidelijke waarde weet het team niet waarom iets belangrijk is en kan het ook geen slimme keuzes maken in de uitwerking.
Een goede story voor een webshop in tuinmeubelen: "Als terugkerende klant wil ik mijn bezorgadres automatisch ingevuld zien, zodat ik sneller kan afrekenen." De rol is duidelijk, de functionaliteit is concreet en de waarde is helder. Vergelijk dat met "adresveld automatisch vullen": dan weet je wat er moet gebeuren, maar niet voor wie en waarom, en dus ook niet wat er gebeurt als het niet lukt.
De drie C's
User stories rusten op drie pijlers, de drie C's. Het kaartje (Card) is slechts de geheugensteun; er past met opzet niet veel op. Het echte werk gebeurt in het gesprek (Conversation) tussen team, Product Owner en gebruikers. En de bevestiging (Confirmation) zit in de acceptatiecriteria: hoe weet je dat de story af is?
Acceptatiecriteria formuleer je concreet en toetsbaar. Niet "het wachtwoord moet veilig zijn", maar "het wachtwoord telt minimaal acht tekens en bevat een hoofdletter en een cijfer". Pas dan kan het team objectief vaststellen of de story klaar is, en pas dan kan de Product Owner hem zonder discussie accepteren. Acceptatiecriteria staan los van de Definition of Done uit hoofdstuk 2: de Definition of Done geldt voor alles wat het team oplevert, de acceptatiecriteria gelden voor deze ene story.
INVEST
Niet elke zin in het Als-wil-zodat-formaat is automatisch een goede story. Het acroniem INVEST geeft je zes criteria om dat te toetsen.
I van Independent: de story is los van andere stories te bouwen. N van Negotiable: de inhoud staat open voor gesprek en is niet dichtgetimmerd. V van Valuable: de story levert duidelijke waarde voor de gebruiker. E van Estimable: het team kan inschatten hoeveel werk het kost. S van Small: de story past binnen één sprint, bij voorkeur ruim. T van Testable: je kunt objectief vaststellen of hij klaar is.
In de praktijk zijn Estimable en Small de twee waar het meestal misgaat, en vaak tegelijk. Kan het team niet schatten, dan is de story te groot of te vaag. Splitsen is dan de oplossing: niet in bouwstappen ("eerst de database, dan het scherm"), maar in kleinere stukken die elk op zichzelf waarde opleveren.
Backlog refinement
Een backlog die maandenlang ongemoeid blijft, veroudert. Daarom plant het team regelmatig een refinement-sessie, vaak één of twee keer per sprint. Het team loopt samen met de Product Owner door de bovenste items van de backlog. Stories worden verduidelijkt, te grote stories worden gesplitst, prioriteiten worden bijgesteld en er worden eerste schattingen gemaakt.
Het doel is dat de bovenkant van de backlog altijd sprint-klaar is. Begint de volgende Sprint Planning, dan liggen er voldoende heldere, geschatte en geprioriteerde stories klaar. Refinement is geen event uit de vijf van scrum, maar een doorlopende activiteit; teams reserveren er meestal een vast uur per week voor.
Een team bij een zorgverzekeraar heeft een story op de backlog staan: "Als verzekerde wil ik mijn declaraties online indienen zodat ik geen post hoef te sturen." Bij de refinement schat de helft van het team hem op 8 punten en de andere helft op 40. Dat verschil is het signaal: de story is niet Estimable, en dus te groot. Ze splitsen hem in drieën. Eén: een foto van een bon uploaden en opslaan. Twee: het bedrag en de datum invullen bij die bon. Drie: de status van de declaratie kunnen volgen. Alle drie leveren op zichzelf waarde op, alle drie passen ze in een sprint van twee weken, en alle drie krijgen ze bij de tweede schattingsronde 5 of 8 punten. De eerste ging mee in de volgende sprint, de derde staat nog steeds op de backlog en niemand mist hem.
Prioriteren met MoSCoW
In hoofdstuk 1 zag je waarom prioriteren in agile geen bijzaak is: tijd en budget liggen vast, dus de scope beweegt mee. Vraag een opdrachtgever wat er in moet en je krijgt een lange lijst. Vraag wat het belangrijkst is en het antwoord is vaak: alles. Maar als alles even belangrijk is, is niets belangrijk, en versnippert het team over te veel taken tegelijk.
MoSCoW is een acroniem waarin elke medeklinker een categorie aanduidt; de o's maken het woord alleen uitspreekbaar. Let op de schrijfwijze, ook die kan in het examen voorkomen.
Must have is wat absoluut in deze release moet zitten. Laat je een Must vallen, dan is de oplevering mislukt. De toets: kun je het product zonder deze functionaliteit überhaupt opleveren? Is het antwoord nee, dan is het een Must. In een webshop is "klant kan afrekenen" een Must; zonder die functie heb je geen webshop, hoe mooi de productpagina's ook zijn.
Should have is belangrijk maar niet kritisch. Je doet je best om het te leveren, maar als de tijd dringt kan het naar een volgende release. De oplevering blijft werkbaar zonder, ook al voelt het ongemakkelijk. "Klant ontvangt een orderbevestiging per e-mail" is een Should.
Could have is wenselijk en levert extra waarde, maar valt zonder pijn weg als de tijd op is. Could haves zijn je flexibele buffer. "Klant kan zijn bestelling laten inpakken als cadeau" is een Could.
Won't have this time is bewust uitgesloten voor deze release. Niet vergeten, niet nog te bespreken, maar actief eraf. Juist door dingen op Won't te zetten schep je duidelijkheid en voorkom je scope creep. "Klant kan via spraakopdracht bestellen" is voor nu een Won't; misschien volgend jaar.
De 60-20-20-regel
De kracht van MoSCoW zit in de verdeling. De richtlijn is 60-20-20: ongeveer 60 procent van je inspanning gaat naar Must haves, 20 procent naar Should haves en 20 procent naar Could haves. Won't haves kosten per definitie geen inspanning. Houd je je hieraan, dan heb je 40 procent ingebouwde buffer. Loopt het tegen, dan offer je eerst Could op, daarna eventueel Should, en blijft je Must overeind.
Een sprint die voor 90 procent uit Must haves bestaat, is geen ambitieuze sprint maar een sprint zonder buffer. Eén tegenvaller en er sneuvelt iets wat niet mocht sneuvelen.
Leg niet alleen vast dát iets een Must is, maar ook waarom. Verandert de context, dan kun je terug naar je redenering in plaats van de discussie opnieuw te voeren. En heronderhandel de prioriteiten bij elke Sprint Planning: wat vorige maand een Could was, kan deze maand een Must zijn.
Een team van zes werkt aan een nieuwe boekingsmodule voor een reisbureau, in sprints van twee weken en met een velocity van ongeveer 30 punten. Na de prioriteringssessie ziet de sprint er zo uit. Must: zoeken op bestemming (8), beschikbaarheid tonen (5), online betalen (5), samen 18 punten, dat is 60 procent. Should: filteren op prijsklasse (5), dat is ruim 15 procent. Could: vakantietips per bestemming (3) en een deelknop voor social media (3), samen 20 procent. Won't have this time: realtime chat met een reisadviseur, expliciet uitgesteld naar de volgende release en dus 0 punten. Halverwege de sprint blijkt de betaalkoppeling zwaarder dan gedacht: 5 punten erbij. Het team schrapt de deelknop en de vakantietips en houdt de vier belangrijkste stories overeind. De sprint eindigt op tijd met een werkend increment, en de marketingafdeling, die om die deelknop had gevraagd, hoort van de Product Owner waarom hij eraf ging en wanneer hij terugkomt.
Pak een project of een product waar je nu aan werkt.
- Schrijf drie user stories in het formaat Als, wil ik, zodat. Dwing jezelf om het zodat-deel echt in te vullen.
- Toets elke story aan de zes INVEST-criteria. Waar zit de zwakke plek? Meestal bij Estimable of Small.
- Formuleer per story twee acceptatiecriteria die je objectief kunt nakijken.
- Maak een lijst van tien wensen en verdeel ze over Must, Should, Could en Won't have this time. Tel daarna het aandeel Must. Zit je boven de 60 procent, wat haal je eruit?
Summary
- Een user story beschrijft kort wie iets wil, wat en waarom: "Als <rol> wil ik <functionaliteit> zodat <waarde>".
- De drie C's: Card is de geheugensteun, Conversation is het echte werk, Confirmation zijn de acceptatiecriteria.
- Acceptatiecriteria zijn concreet en toetsbaar en gelden per story; de Definition of Done geldt voor alles wat het team oplevert.
- INVEST toetst een story op Independent, Negotiable, Valuable, Estimable, Small en Testable.
- Backlog refinement houdt de bovenkant van de backlog sprint-klaar; één of twee keer per sprint, samen met de Product Owner.
- MoSCoW kent Must have (zonder dit is het mislukt), Should have (belangrijk, uitstelbaar), Could have (wenselijk, de buffer) en Won't have this time (bewust uitgesloten).
- De verdeling 60-20-20 over Must, Should en Could bouwt een buffer in; Won't kost geen inspanning.
Een team schat dezelfde story de ene keer op 8 punten en de andere keer op 40, en komt er na twee rondes niet uit. Welk INVEST-criterium staat hier het meest onder druk?
Wat betekent het als een item op Won't have this time staat?
Een sprint is voor 85 procent gevuld met Must haves. Wat is daarvan het grootste risico?