“Hoe lang ben je daar mee bezig?”
Het inschatten van werk kan eigenlijk nooit goed gebeuren. De ervaring leert dat velen toch in de ‘urenvalkuil’ stappen terwijl ‘het team storypoints wilt’. Wat zijn nu eigenlijk storypoints, en hoe ga je er mee om? Hoe kan je op basis van een schatting in storypoints nu afleiden wanneer een item klaar is? Wat is überhaupt het idee van het inschatten van items?
Meten is weten
Laten we teruggaan naar de basis. Zonder vergelijkingsmateriaal is er geen beginnen aan. Ga dus bijhouden hoe lang er aan een item gewerkt wordt! Zo krijg je als ontwikkelaar ook inzicht in hoe jouw schattingen zich verhouden tot elkaar. Was item X daadwerkelijk 3 storypoints aan werk, of was het misschien minder? Tijdens het afronden van de userstory is het aan het teamlid om de tijd in te vullen (in uren bijvoorbeeld) die er aan gespendeerd is. Zo wordt inzichtelijk of de zwaarte van het item proportioneel is aan de storypoints die er gegeven zijn.
Capaciteit
Houdt daarnaast de beschikbaarheid van alle leden van het team ook bij. Want het heeft geen zin om iemand mee te nemen in de planning wanneer deze immers op vakantie is. Als je maar 60% capaciteit hebt, plan dan dus niet voor 100% in.
Wat zijn nu eigenlijk storypoints?
Wat is 1 storypoint/hoe lang duurt 1 storypoint? Dat is een vraag die zelfs menig ontwikkelaar af en toe stelt. Minder dan 2 storypoints.
Het maakt namelijk ook niet uit “wat” of “hoeveel” 1 storypoint is. Het is een manier om user story’s met elkaar te kunnen vergelijken. Mijn voorstel is dus om dit te koppelen aan iets anders dan cijfers, bijvoorbeeld letters. Zo is de kans op verwarring (en zeker bij stakeholders en project managers) met uren minder snel gemaakt.
Wat als er een userstory “precies” tussen twee andere items invalt?
Pas je dan je schaal aan? In de eerste instantie zegt mijn gevoel van wel maar dit hoeft in principe niet. Je kan immers een nieuwe waarde verzinnen, of de userstory opsplitsen en herschrijven zodat het 2 of meer story’s zijn die beter in de schaal passen.
De deadline halen
Wanneer is dan nou de deadline? Wanneer is het af? Naast de tal van vergelijkbare metaforen zijn zowel je huis alsmede softwareprojecten nooit af. Wat je wel kan doen is inzicht geven in de waarschijnlijkheid wanneer bepaalde userstory’s geïmplementeerd zijn.
Op basis van de data kan er een projectie gemaakt worden van het ingeschatte(!) werk wat er nog op de backlog te vinden is. Kortom: er moeten storypoints aanwezig zijn. Daarnaast moeten er al een aantal items zijn weggewerkt, zodat je kan rekenen met data die gebaseerd is op feiten: de capaciteit (zowel aankomend als die uit het verleden) en de tijd die er verspijkerd is aan de items die tot dusver gedaan zijn. Daarnaast is de prioritering van de backlog essentieel om te weten in welke volgorde de items worden opgepakt! Pro tip: gooi ook items weg van de backlog als deze niet (meer) relevant zijn.
Denk er daarnaast aan dat verschillende items met hetzelfde aantal storypoints niet even lang hoeven te duren om af te ronden! Er is dus een minimale en een maximale duur van het implementatie traject. Het antwoord ligt hier vaak in het midden. Echter is de communicatie naar de stakeholders (de eindklant) wel helder.
Het is veel beter om als project manager te kunnen zeggen: “Binnen 4 en 8 weken is het af” dan om te zeggen “Over 5 weken is het af” en het dan niet te halen. Zo voorkom je teleurstelling en schep je geen onnodige verwachtingen.
