Werk inschatten voor product owners

Het inschatten van werk binnen Scrum is cruciaal, niet alleen voor de teams maar vooral voor de product owner die de brug vormt tussen het team en de stakeholders. Deze inschattingen bieden inzicht in kosten, tijdsduur en complexiteit. In deze blog gaan we dieper in op het onderwerp ‘werk inschatten’ en beschrijven we onze favoriete technieken voor product owners.

Een van de uitdagingen waar een Scrum team tegenaan loopt is het inschatten van werk. We werken Agile, maar toch wil de opdrachtgever of stakeholder weten hoeveel het allemaal gaat kosten. En dan natuurlijk de hamvraag: wanneer is het af?

De refinement maakt geen deel uit van de ‘officiële’ Scrum rituelen. Wij zien in de praktijk dat de refinement wel degelijk in agenda’s van Scrum teams voorkomt. Soms een vaste afspraak, soms alleen als het echt nodig is. Tijdens een refinement is het doel om tot goede inschattingen van het werk te komen door iedereen individueel een inschatting te laten maken. Hoe frequent en hoe lang de refinement is, is afhankelijk van ervaring en expertise binnen het team en van het product zelf.

Tijdens de sprintplanning wil je samen met het team vaststellen wat er in alle redelijkheid binnen een sprint gerealiseerd kan worden. Hiervoor is het noodzakelijk om een inschatting te maken van de hoeveelheid werk per PBI, in combinatie met de hoeveelheid werk die het team aankan.

Als het team een tijdje met elkaar samenwerkt worden de schattingen beter: realistischer en meer consistent. Je begrijpt elkaar beter en hebt geleerd van eerdere inschattingen ten opzichte van de daadwerkelijk geleverde inspanning.

Vanuit ervaring of theorie kunnen we daar een hoop van vinden, maar het feit blijft dat de beslissers een gevoel willen hebben bij hoe complex de werkzaamheden zijn. Dat zorgt ervoor dat het in de praktijk wel degelijk een belangrijk onderdeel is van het Scrum proces.

Scrum schrijft niet voor hoe dit moet worden gedaan en het is dus aan het team om de werkwijze te bepalen. Hieronder geven we wat opties met bijbehorende tooling. Story points zijn populair om tot een inschatting te komen. Daarnaast kan je gebruik maken van T-shirt sizing. Ook zien we in de praktijk dat er uren of dagdelen aan stories worden toegekend.

Story points is het inschatten van complexiteit door middel van het toekennen van punten. Hiervoor wordt over het algemeen de zogenaamde Fibonacci reeks gebruikt. Het idee is dat er een eerste story ingeschat wordt en deze als ijkpunt geldt voor het inschatten van andere stories. Vervolgens krijgt het team naarmate het meer sprints met elkaar draait gevoel bij deze punten en zal dit proces steeds soepeler gaan lopen. De afgeronde story points in een sprint resulteren in een getal wat de velocity van het team bepaalt. Op basis van de velocity kan vervolgens worden bepaald hoeveel punten en complexiteit het team in een sprint aan kan. Belangrijk hierbij is wel dat de teamsamenstelling niet te veel veranderd.

Inschatten gebeurt binnen Scrum teams het meeste met ‘planning poker’. Tijdens de refinement hebben de developers allemaal een set kaarten met de gebruikte waarden en iedereen legt een gesloten kaart met inschatting neer. Vervolgens draai je alle kaarten tegelijk om en lichten de eigenaren van de hoogste en laagste kaarten hun schatting toe. Dit doe je totdat er consensus is over de schatting en dat wordt als (groeps)waarheid aangenomen en genoteerd als inspanning van de PBI.

Je kent ondertussen ongetwijfeld Miro wel voor het o.a. maken van overzichten met post-its. Maar wist je dat je Miro ook kunt gebruiken voor planning poker? Ook zijn er online diverse betaalde en gratis diensten te vinden om het planning poker proces te faciliteren. Een goed en gratis voorbeeld hiervan is Scrumpoker-online.org. Een andere tool waar we enthousiaste verhalen over horen is AirFocus, deze online (betaalde) tool biedt o.a. mogelijkheden om prioritering te bepalen.

Eventueel kan je ook dit filmpje bekijken waarin planning poker wordt uitgelegd.

T-shirt sizing is een methode van inschatten waarbij geen punten toe worden gekend, maar een grootte/complexiteit toe wordt gekend in het format XS, S, M, L, XL, etc. Dit zijn allemaal relatieve eenheden, wat het veel makkelijker maakt voor ons als mens om te schatten dan in de absolute eenheid van tijd. Deze techniek wordt meestal gebruikt om complexiteit in te schatten op het moment dat nog niet alle details 100% zijn uitgeklaard, maar we toch snel een gevoel willen krijgen bij de complexiteit van een lijst met requirements. Het team heeft wel een referentie nodig waar iedereen hetzelfde gevoel bij heeft, bijvoorbeeld ‘het maken van één knop, inclusief styling en een foutafhandeling, exclusief de functionaliteit erachter, kost 1 storypoint of is maat XS.  Er zijn geen online tools hiervoor. Het planning poker proces kan worden geleend om dit voor elkaar te krijgen en een chat venster in een online meeting room kan ‘worst-case-scenario’ al uitkomst bieden.

#NoEstimates is een filosofie die erop gericht is werk gedaan te krijgen wanneer de waarde bekend is. Het uitgangspunt van #NoEstimates is dat schattingen vaak een verspilling van tijd zijn, vooral in kleine stappen wanneer gezond verstand en planning de planning effectiever kunnen maken. Deze filosofie richt zich op het maximaliseren van flow en werkende software, met een duidelijke focus op werkende software. Dit is een radicalere interpretatie van Agile dan de meeste andere, maar heeft verschillende aanhangers die de focus op het gedaan krijgen van werk waarderen.

Binnen Agile wordt er vaak neergekeken op het inschatten van het aantal benodigde uren. Het voelt voor velen al snel als fixed scope of fixed price aan. Toch wordt deze manier van inschatten nog steeds veel gebruikt en zijn er situaties waar deze methode wenselijk is. Het inschatten in uren staat het Agile proces in ieder geval niet per definitie in de weg. Het probleem is echter wel dat het vaak extreem lastig is om exact in uren in te schatten hoeveel werk iets is en dus de nauwkeurigheid vaak te wensen overlaat. We zijn als mensen gewoon niet heel erg goed in het exact inschatten van hoeveel tijd iets kost. Dit is zeker niet het geval als het om complexe en/of creatieve taken gaat.

Ondanks dat we onszelf als bovengemiddeld pragmatisch inschatten, zouden we deze methode afraden, omwille van het gegeven dat het te vaak leidt tot niet gehaalde verwachtingen. De enige uitzondering die we willen meegeven is wanneer het gaat om kleine projectjes, waarbij de kop en staart minder dan 1 sprint is qua doorlooptijd.

De rol van de product owner kan per bedrijf erg verschillen, meer hierover vertellen wij in onze product owner basistraining. Wat in ieder geval NOOIT je rol is, is om te gaan zitten drukken op het team om het sneller gereed te krijgen dan het benodigde tijdsbestek. Wij schatten de kans op 100% dat je van een koude kermis thuiskomt.

Maar hoe ga je dan om met projecten waar hoge druk op staat? Je mag het team uitleggen dat er druk op staat, dat is in sommige gevallen zelfs aan te raden. Transparantie rondom ‘business urgency’ is heel normaal, zeker als het gaat om bijvoorbeeld wet- en regelgeving of tussentijdse budget wijzigingen.

In alle gevallen is het zaak om:

En moet je dan als product owner wel of niet mee inschatten? Het korte antwoord is nee. Je bent als product owner geen onderdeel van de HOE, dus laat het dan ook over aan de mensen die het daadwerkelijk gaan doen.

Het iets langere antwoord is dat het in sommige gevallen nuttig kan zijn. Wij hebben meerdere klanten waarvan de product owner wordt gevraagd om mee in te schatten. Het leidt tot interessante discussies over de oplossingsrichting, wat het product ten goede doet. Tegelijkertijd denken we dat het zaak is om die discussies eerder te voeren, bijvoorbeeld tijdens de refinements. In de gevallen dat de product owner mee inschat is het meer een ‘safety net’. Het is goed dat die er zijn, maar in een optimaal proces zou het onnodig moeten zijn.

Het inschatten van werk is voor product owners een zeer nuttige tool om de scope te bepalen, maar mag nooit als de heilige graal worden gezien. In een goed geolied proces en in een goed functionerend team is het een van de radartjes, maar nooit de grootste. De grootste radar blijft wat ons betreft een product dat gebruikers graag willen gebruiken en dat op die manier veel waarde creëert voor de business. Wil je meer weten over het inschatten van werk en de rituelen van Scrum, en hoe je deze in jouw praktijk kan toepassen? Bekijk onze eendaagse product owner basistraining.

Ben jij op zoek naar een product owner die jouw scope kan bepalen en waarde kan toevoegen aan jouw product? Bekijk hier onze werving en selectie voor product owners.