Een schatting maken is lastig. Voor softwareontwikkelaars is dit een van de moeilijkste aspecten van het werk, misschien wel het moeilijkste aspect. Er moet rekening worden gehouden met een hele reeks factoren die producteigenaren helpen beslissingen te nemen die van invloed zijn op het hele team en het bedrijf. Met alles wat op het spel staat, is het dan ook niet vreemd dat iedereen, van ontwikkelaars tot hoger management, soms lichtelijk overstuur raakt. Maar dat is niet nodig. Een agile schatting van storypoints is niets meer dan het is: een schatting. Geen bloedeed.
Het is geen verplichting om in het weekend te werken om te compenseren voor het onderschatten van een stuk werk. Maar laten we eens kijken naar een paar manieren om agile schattingen zo nauwkeurig mogelijk te maken.
Samenwerken met de producteigenaar
Bij agile ontwikkeling is het de taak van de producteigenaar om prioriteit te geven aan de backlog — de geordende lijst met werk die korte beschrijvingen bevat van alle gewenste functies en oplossingen voor een product. Producteigenaren leggen vereisten van het bedrijf vast, maar begrijpen niet altijd de details van de implementatie. Een goede schatting kan de producteigenaar dus nieuw inzicht geven in de mate van inspanning die vereist is voor elk werkitem, op basis waarvan de beoordeling van de relatieve prioriteit van elk item kan worden aangepast.
Wanneer het engineeringteam begint met het schattingsproces, komen er meestal vragen naar boven over vereisten en userstory's. En dat is prima: die vragen dragen eraan bij dat het hele team het werk beter begrijpt. Met name voor producteigenaren helpt het om werkitems via storypoints op te splitsen in gedetailleerde werkonderdelen en schattingen, om vervolgens de juiste prioriteit toe te kennen aan alle (en mogelijk verborgen) werkgebieden. En als er eenmaal schattingen zijn aangeleverd door het ontwikkelingsteam, is het niet ongebruikelijk dat een producteigenaar items in de backlog anders ordent.
Agile storypoints inschatten is een teamsport
Iedereen (ontwikkelaars, ontwerpers, testers, engineers ... oftewel iedereen) uit het team betrekken is essentieel. Elk teamlid heeft een ander perspectief op het product en het werk dat nodig is om een userstory te leveren. Als productmanagement bijvoorbeeld iets wil doen dat eenvoudig lijkt, zoals support van een nieuwe webbrowser, moeten ontwikkeling en QA zich laten horen omdat hun ervaring hen heeft geleerd welke beren er op de weg kunnen verschijnen.
Evenzo vereisen ontwerpwijzigingen niet alleen de input van het ontwerpteam, maar ook die van ontwikkeling en QA. Als een deel van het bredere productteam niet deelneemt aan het schattingsproces, betekent dit schattingen van lagere kwaliteit, een lager moreel omdat belangrijke medewerkers zich niet betrokken voelen en aantasting van de kwaliteit van de software.
Laat je team dus niet het slachtoffer worden van schattingen die in een vacuüm zijn gemaakt. Dat is namelijk een garantie voor mislukking!
Wil je zelf aan de slag met storypoints? Meld je eerst aan of log in bij Jira
Storypoints versus uren
Traditionele softwareteams geven schattingen in een tijdformaat van dagen, weken en maanden. Veel agile teams zijn echter overgestapt op storypoints. Storypoints zijn maateenheden voor het uitdrukken van een schatting van de totale inspanning die nodig is om een item in de productbacklog of een ander stuk werk volledig te implementeren. Teams wijzen storypoints toe afhankelijk van de complexiteit van het werk, de hoeveelheid werk en risico of onzekerheid. Er worden waarden toegewezen om werk effectiever op te kunnen splitsen in kleinere stukken, zodat rekening kan worden gehouden met onzekerheid. In de loop van de tijd helpt dit teams te begrijpen hoeveel ze in een bepaalde periode kunnen bereiken. Bijkomende voordelen zijn dat er consensus wordt opgebouwd en er toewijding ontstaat voor de oplossing. Het klinkt misschien contra-intuïtief, maar deze abstractie is eigenlijk nuttig omdat het team er hierdoor toe wordt aangezet strengere beslissingen te nemen over de moeilijkheidsgraad van het werk. Dit zijn enkele redenen om storypoints te gebruiken:
- Datums houden geen rekening met het niet-projectgerelateerde werk dat onvermijdelijk onze dagen binnensluipt: e-mails, vergaderingen en gesprekken waarbij een teamlid mogelijk betrokken is.
- Datums hebben een emotionele connotatie. Een relatieve schatting neemt die emotionele connotatie weg.
- Elk team zal werk op een iets andere schaal schatten, wat betekent dat hun snelheid (gemeten in punten) natuurlijk anders zal zijn. Dit maakt het op zijn beurt onmogelijk om politiek te bedrijven met snelheid als wapen.
- Zodra je het eens bent over de relatieve inspanning van elke storypointwaarde, kun je snel punten toewijzen zonder al te veel discussie.
- Storypoints belonen teamleden voor het oplossen van problemen op basis van moeilijkheidsgraad, niet de bestede tijd. Dit houdt teamleden gefocust op het realiseren van waarde, en niet op het besteden van tijd.
Helaas worden storypoints vaak verkeerd gebruikt. Storypoints werken niet als ze worden gebruikt om mensen te beoordelen, gedetailleerde tijdlijnen en middelen toe te toewijzenof als ze onterecht worden aangezien als maatstaf voor productiviteit. Teams moeten storypoints gebruiken om de omvang van het werk en de prioritering van het werk te begrijpen. Bekijk deze roundtable met experts uit de branche voor een diepgaande discussie over storypoints en schattingsprocessen. Lees snel verder voor meer tips voor agile schattingen.
Storypoints en Planning Poker
Teams die beginnen met storypoints gebruiken een oefening met de naam Planning Poker. Bij Atlassian is Planning Poker een gangbare praktijk in het hele bedrijf. Het team neemt een item uit de backlog, bespreekt dit kort en elk lid maakt in zijn hoofd een schatting voor de benodigde tijd. Vervolgens houdt iedereen een kaart omhoog met het getal dat hun schatting weergeeft. Als iedereen het eens is, geweldig! Zo niet, neem dan even de tijd (maar niet te lang, een paar minuten is genoeg) om de redenering achter de verschillende schattingen te begrijpen. Onthoud echter dat schatting een algemene activiteit moet zijn. Als het team te veel in detail verzandt, haal dan even diep adem en breng de discussie weer op niveau.
Wil je het eens proberen?
- Installeer deze Planning Poker-app
- Meer informatie over Planning Poker
Schat slimmer, niet moeilijker
Geen enkele individuele taak mag meer dan 16 uur werken omvatten. (Als je storypoints gebruikt, kun je bijvoorbeeld besluiten dat 20 punten de bovengrens is.) Het is gewoon te moeilijk om individuele werkitems groter dan dat met een hoog vertrouwen in te schatten. En dat vertrouwen is vooral belangrijk voor items bovenaan de backlog. Wanneer iets boven de drempel van 16 uur (of 20 punten) van je team wordt geschat, is dat een signaal om het op te splitsen in meer gedetailleerde stukken en opnieuw in te schatten.
Geef voor items lager in de backlog een ruwe schatting. Tegen de tijd dat het team daadwerkelijk aan die items begint te werken, kunnen de vereisten zijn veranderd en zal je toepassing zeker zijn veranderd. Eerdere schattingen zullen dus niet zo nauwkeurig zijn. Verspil geen tijd aan het schatten van werk dat waarschijnlijk zal gaan verschuiven. Geef de producteigenaar een indicatie die gebruikt kan worden om de productroadmap overeenkomstig te prioriteren.
Leer van schattingen uit het verleden
Retrospectieven zijn een tijd voor het team om inzichten uit eerdere iteraties op te nemen, inclusief de nauwkeurigheid van hun schattingen. Veel agile tools (zoals Jira) volgen storypoints, wat het reflecteren op en opnieuw kalibreren van schattingen een stuk eenvoudiger maakt. Probeer bijvoorbeeld de laatste 5 userstory's op te halen die het team heeft afgeleverd met de storypointwaarde 8. Bespreek of elk van deze werkitems een vergelijkbare inspanning heeft gekost. Zo niet, bespreek dan waarom. Gebruik dat inzicht voor toekomstige schattingen.
Net als al het andere in agile, is schatting iets dat je in de praktijk ervaart. Met de tijd wordt je steeds beter.
Gerelateerde resources
