Genormaliseerde Story Points in SAFe – hoe en waarom?
SAFe4 stelt voor dat Story Points binnen de productontwikkeling gestandaardiseerd zouden moeten zijn over de verschillende teams heen. Daarvoor biedt SAFe een methode aan waarmee je al in de allereerste Sprint Story Points kunt schatten. Vanuit het perspectief van Scrum lijkt deze aanpak op het eerste gezicht inconsistent met het idee van Story Points. Om deze tegenstrijdigheid op te lossen, bekijken we het idee wat nader.
Wat zijn Story Points eigenlijk?
Story Points zijn, kort gezegd, een willekeurig meetinstrument om de inspanning van een Backlog Item te kwantificeren. Ze helpen de developers om hun capaciteit beter te plannen – en de Product Owner om een beeld te krijgen van wat er in de komende weken en maanden haalbaar is. Zo kun je bijvoorbeeld deadlines en de omvang van een release voorspellen.
Een extra voordeel wordt door Mike Cohn voorgesteld: als je de Velocity en maandelijkse kosten van een team kent, kun je kostenramingen maken voor Backlog Items. Op die manier kun je de kostenefficiëntie van de ontwikkeling optimaliseren. Een Backlog Item kan bijvoorbeeld onrendabel blijken zodra de kosten bekend zijn. Zo kan de Product Owner vroegtijdig beslissen of een Story wordt aangepast of volledig geschrapt.
SAFe pakt dit idee op in het WSJF-concept: Features met de beste kosten-batenverhouding zouden voorrang moeten krijgen.
Het belangrijkste om zo'n aanpak te laten werken, is dat alle betrokkenen hetzelfde begrip van Story Points hebben. Omdat Story Points voor verschillende teams best iets anders kunnen betekenen, moet je voorzichtig zijn wanneer je de waarden buiten het team bekijkt.
Wat zijn Genormaliseerde Story Points?
In SAFe is de ontwikkeleenheid voor het product een Agile Release Train (ART), een „Team of Teams".
Net zo belangrijk als het in Scrum is dat alle betrokkenen in het team een Story Point op dezelfde manier begrijpen, is het in SAFe belangrijk dat alle betrokkenen in de ART een Story Point op dezelfde manier begrijpen.
Als teams Story Points verschillend zouden interpreteren, zou de Product Manager compleet verschillende schattingen krijgen, afhankelijk van welk team een item heeft geschat. De schattingen die zo ontstaan zouden vanuit businessperspectief totaal onbruikbaar zijn. Daarmee zou het hele schattingsproces nutteloos zijn en de schattingen waardeloos.
Daarom stelt SAFe voor dat er, net zoals er binnen het Scrum Team een gedeeld begrip van Story Points nodig is, ook tussen de afzonderlijke teams in de ART een gedeeld begrip van Story Points nodig is om zinvol te kunnen schatten.
Waarom zijn individuele Story Points per team geen goed idee?
In SAFe delen alle teams in de ART één gemeenschappelijke, centrale Program Backlog. Deze Program Backlog consolideert alle werkzaamheden van de ART, ongeacht welk team het werk later daadwerkelijk oppakt.
Een sleutelconcept van agiliteit is dat werk onafhankelijk van de persoon zou moeten zijn, want specialisatie leidt tot lokale optimalisatie.
Vanuit Lean-perspectief is het vaak beter als een langzamer team direct met het werk begint, in plaats van dat je met belangrijke zaken wacht op het snellere team.
Vooral wanneer meerdere teams samenwerken, kan een langzamer team vaak al een deel van de waarde leveren voordat het snellere team beschikbaar wordt om mee te doen. Zo wordt de totale doorlooptijd verkort en de betrokkenheid van het snellere team tot aan de uiteindelijke oplevering verminderd.
Als Story Points tussen teams verschillend zijn, moet elk afzonderlijk Backlog Item door elk afzonderlijk team geschat worden, totdat je begrijpt welk team wanneer klaar zou kunnen zijn. Dat is natuurlijk mogelijk, maar betekent enorm veel verspilling en overhead.
Zijn de Story Points daarentegen over teams heen genormaliseerd, dan heb je slechts één enkele schatting van één enkel team nodig. Wanneer je vervolgens naar de Velocity van de afzonderlijke teams kijkt, zie je snel en eenvoudig hoe lang het zou duren.
Een extra voordeel van genormaliseerde Story Points is: als Team A de ondersteuning van Team B nodig heeft om een belangrijke deadline te halen, weet de Product Owner van Team B direct hoeveel Team B uit zijn Backlog zou moeten schrappen om de Stories van Team A over te nemen. Omdat er geen nieuwe schatting nodig is, ontstaan er geen vertragingen en geen extra inspanning voor schattingen.
Hoe normaliseert SAFe de Story Points precies?
In het allereerste Program Increment is de ART nieuw. Noch de individuele teams, noch de personen in de ART hebben ooit in precies deze samenstelling gewerkt. De teams bevinden zich in de "Storming Phase" – net als de ART zelf.
Dat betekent op zijn beurt: de Working Agreements zijn nog onduidelijk. De DoD is een vaag ideaal dat nog nooit in de praktijk is getest. Overal kunnen struikelblokken liggen. Afhankelijk van hoe de productontwikkeling verloopt, is waarschijnlijk ook de werkomgeving nieuw en onbekend. Iedereen bevindt zich op een witte vlek op de kaart – elke schatting is koffiedik kijken.
Een mogelijke aanpak zou nu zijn om samen te bespreken welke Story je als referentie kiest, hoe je punten definieert, hoeveel punten de referentie-Story krijgt – en van daaruit verder te werken. Deze discussie leidt tot verdere discussies, die op zich geen waarde vanuit klantperspectief opleveren.
SAFe vermijdt deze aanpak en stelt het volgende voor: Relatief Schatten
In de allereerste PI Planning begin je ermee dat het team het kleinste item uit zijn Backlog selecteert en daar een "1" aan toekent. Het eerstvolgende grotere item krijgt een "2", en zo werk je je verder langs een reeks gebaseerd op de Fibonacci-getallen (1,2,3,5,8,13,20,40,100): Hebben we een item van dezelfde grootte als een bekend item? Zo ja, dan krijgt het hetzelfde getal – als het het tot nu toe grootste is, krijgt het een passend getal. Als we geen goede referentie hebben en moeten springen, zou "3" minstens twee keer zo groot zijn als "1", en "8" minstens twee keer zo groot als "3" enz. Zo kun je via een heel eenvoudige aanpak zonder exacte kennis een inschatting maken van wat het team voor zich heeft.
Dat is natuurlijk puur gokken en de waarden zijn behoorlijk onnauwkeurig. Maar aangezien we nog geen ervaringswaarden hebben, is deze aanpak net zo goed als elke andere. Het belangrijkste is dat de teams bij de Stories over "Wat", "Waarom" en potentiële risico's discussiëren.
Hoe wordt Velocity berekend aan de hand van Genormaliseerde Story Points?
Om het nog eens te benadrukken: in het eerste Program Increment hebben we geen flauw idee hoeveel Story Points een team daadwerkelijk haalt. Omdat we echter PT-schattingen hebben, stelt SAFe de volgende aanpak voor bij de eerste PI-Planning:
We weten hoeveel teamleden ons team heeft. We weten ook op hoeveel dagen we van plan zijn om in een iteratie aan het werk te zijn (natuurlijk weet je niet wanneer je ziek wordt – dat risico blijft gewoon bestaan).
Een gebruikelijke SAFe-iteratie duurt 2 kalenderweken, dus 10 werkdagen. Dit getal kun je vermenigvuldigen met het aantal teamleden:
Base Capacity = 10 * Team Members
Daarvan trekken we de dagen af waarop teamleden niet aanwezig zijn:
Aangepaste Capacity = Base Capacity – (Feestdagen * Team Members) – (individuele afwezigheidsdagen)
Daarvan trekken we nog eens 20 procent af – want plannen op 100 procent bezetting leidt altijd tot een disaster!
Initiële Velocity = Aangepaste Capacity * 0.8
Hier een voorbeeld:
Team Trolls bestaat uit 6 ontwikkelaars. Er is in de volgende iteratie één feestdag en Toni moet op vrijdag iets persoonlijks regelen.
Base Capacity = 106 = 60 SP
Aangepaste Capacity = 60 SP (Base) – 16 SP (Feestdagen) – 1 SP (Afwezigheid) = 53 SP
Initiële Velocity = 53 SP * 80 procent = 42 SP
Team Trolls zou dan iteratie 1 inplannen met 42 Story Points. Als de aantallen van de Stories niet helemaal kloppen, is het altijd beter om iets eronder te blijven dan jezelf te overvragen. De Trolls zouden daarom kunnen besluiten om met 39 SP's de eerste iteratie in te gaan.
Wat gebeurt er in de loop van de tijd met de Genormaliseerde Story Points?
In de eerste iteratie hebben we gewoon geraden. Raden is beter dan niets. En daarna komt Inspect+Adapt aan bod. Misschien hebben de Trolls geleerd dat ze door de backlog heen vliegen als een warm mes door boter. Dan zouden ze de volgende keer natuurlijk een paar Story Points meer pakken. Misschien hebben de Badgers geleerd dat ze veel voor andere teams moeten doen (zoals bijvoorbeeld kennisoverdracht). Dan zouden ze in de toekomst niet meer zoveel Story Points op zich nemen.
Zo zou de ART-Velocity zich in de loop van de tijd kunnen ontwikkelen:
Zoals we in dit voorbeeld zien, gebruiken teams individueel Inspect+Adapt en bewaken ze hun eigen Velocity. De Product Manager krijgt regelmatig feedback om de algehele productplanning en de PI-doelen (en eventueel Releasedoelen) hierop aan te passen.
Herschattingen van eerder geschatte Backlog-Items zijn niet meer nodig. Wanneer nieuwe onderwerpen bekend worden, kunnen „Done" Stories als referentie worden gebruikt om toekomstige Backlog-Items consistent te schatten ten opzichte van bestaande en eerdere items. De koppeling met de persoonsdag verdwijnt.
Voorzichtig met Genormaliseerde Story Points
Story Points zijn geen business-metric! Velocity ook niet. Het zijn vereenvoudigde planningsmetrics die de inspanning van het plannen minimaliseren en tegelijkertijd voldoende vertrouwen geven in de haalbaarheid.
Deze metrics hebben in de ART dezelfde beperkingen als in Single-Team Scrum. De volgende antipatterns moeten worden vermeden.
Wat je absoluut niet moet doen:
Schattingen als "correct" beschouwen. Het zijn – en blijven – schattingen.
Voortgang meten op basis van "geleverde Story Points". Bruikbare producten zijn de primaire voortgangsmaatstaf!
Teams vergelijken op basis van hun Velocity. Velocity is geen prestatiemaatstaf!
De structuur van de ART optimaliseren op basis van Velocity-waarden. Een ART is een zeer complex adaptief systeem!
Proberen om Velocity constant te houden of te verhogen. Capaciteitsplanning is risicominimalisering. Ze is onderworpen aan de realiteit. Velocity is slechts een indicator die de betrouwbaarheid van de planning verhoogt!
Wanneer moet je genormaliseerde Story Points toepassen?
Het normaliseren van Story Points lost een probleem op dat zonder schaling helemaal niet bestaat. Het beantwoordt de vraag: „Wat gebeurt er als andere teams aan deze Story werken?" Daarvoor moet het begrip van een Story Point over teamgrenzen heen eenduidig zijn.
Zo kunnen in het ART Backlog items relatief eenvoudig tussen teams heen en weer geschoven worden, om in plaats van de bezetting van individuele teams de totale waarde van het geleverde product te maximaliseren.
Totdat betere informatie beschikbaar is, kun je met een heel eenvoudige benchmark en relatieve schatting een goed overzicht creëren. Uit de afgeronde Stories kunnen dan „passend geschatte", aansprekende Stories als referentie voor de toekomst gekozen worden. Herschattingen zijn er niet. Het aanvankelijk eenvoudig aangenomen verband tussen Story Points en persoonsdagen verdwijnt binnen de kortste tijd. Dat moet gebeuren, zodat Story Points teamoverstijgend consistent blijven.
Ook voor de initiële Velocity-planning gebruiken we bij gebrek aan betere informatie de heel eenvoudige vuistregel „80 procent van de beschikbare tijd". Zodra de eerste iteratie is afgerond, gebruiken we het werkelijke resultaat als referentie voor de toekomst en passen we ons adaptief aan. Binnen enkele iteraties lost ook de correlatie tussen Velocity en tijdscapaciteit op. Ook dit moet gebeuren, zodat Velocity als planningstool in het ART consistent en zinvol gebruikt kan worden.
In het ART is het nog moeilijker dan in Single-team Scrum om de verleiding te weerstaan teams op basis van Velocity te beoordelen. De RTE heeft de belangrijke taak om de integriteit van de Story Points te waarborgen door alle pogingen (doorgaans van het management) te blokkeren die de Story Points of Velocity voor andere doeleinden zouden misbruiken.
