Stephan van Rooden

Stephan van Rooden

Gedistribueerd en relatief schatten

LinkedIn
Twitter
WhatsApp
Email

Poker planning met een gedistribueerd team is prima te doen, mits de juiste middelen voor handen zijn. Zo zijn er Google Chrome Apps om te pokeren, apps voor op je smartphone of tablet met een on-line account en gewone websites waar je je kan aanmelden zodat je kan pokeren. Wat als je het moet doen met een simpele shared desktop? Relatief gaan schatten. Hier noem ik het distributed backlog item estimation.

Distributed backlog item estimation

Benodigdheden:

  • 1 Shared desktop voor het hele team.
  • Een conference call zodat iedereen in het team met elkaar kan praten, Sococo / GoToMeeting, webex, AT&T of vergelijkbare tools zijn ook prima.
  • Spreadsheet / text editor zoals Excel of Notepad.

Sessie verloop:

  1. Product owner bespreekt een setje product backlog items die geschat moeten worden.
  2. Wanneer de product owner en het developer team eens zijn over de inhoud van de items, dus over de beschrijving en de acceptatie criteria, de waarde die het toevoegt aan het product en nog andere zaken die eventueel van belang zijn zoals afhankelijkheden en risico’s, maak je een lijst (lijst 1) van de zo juist besproken items (de te schatten items) met alleen hun titel en eventueel nog hun beschrijving erbij.
  3. De product owner pakt een willekeurige item uit lijst 1, bij voorkeur degene die zo op het eerste gezicht de minste werk inspanning vereist, en zet die onderaan de lijst met nog daarboven een lege regel om onderscheidt te maken tussen de nieuwe lijst (lijst 2) die we nu gaan opbouwen en de lijst waarmee we begonnen zijn.
  4. Dan pakt de product owner een willekeurige andere item uit lijst 1 en vraagt aan het team of het meer, gelijke of minder inspanning vergt om deze item te realiseren ten op zichte van de item uit lijst 2. Als het team aangeeft dat het meer of gelijke inspanning vereist, dan plaatst de product owner het item boven het item uit lijst 2. Bij mindere inspanning plaatst de product owner het onder het item uit lijst. Vervolgens pakt de product owner een volgende item uit lijst 1 en verzoekt het team weer of zij dit item relatief kunnen plaatsen ten op zichte van één van de items uit lijst 2. Dit herhaal je tot lijst 1 op is. Verwijder de lege regel boven lijst 2. Je hebt nu één lijst die van boven tot onder gesorteerd is op meest tot minste inspanning vereiste product backlog items.
  5. Nu begint de product owner bij het onderste item in de lijst en vraagt aan het team hoeveel story points zij dit item toedichten. Noem daarbij hard op waarden als 0,5, 1, 2 of 3. Meer mag ook natuurlijk. Als het team niet binnen een paar tellen kan aangeven hoeveel het is, loop dan iedere developer af met de vraag wat zij inschat. Schrijf voor iedere developer die waarde op achter het item in de lijst.Bij een developer team van 4 personen zou er kunnen staan: 3325. Vraag dan aan degenen die het hoogst en het laagst afwijken van de rest wat de reden is en laat het developer team tot een consensus komen. Verwijder de tijdelijk ingevoerde getallen (zodat iedereen kan zien wat er geroepen is wereldwijd) en vervang ze voor de juiste, die uiteindelijk gekozen is door het team. Ervaring leert dat met goed doorgesproken backlog items (stap 1) dit nog geen 30 seconden per item hoeft te duren.
  6. Vervolgens pakt de product owner het op één na laatste item op en vraag aan het team of deze de waarde heeft die gelijk is aan de vorige gekozen waarde of een daarop volgende waarde. Als het vorige item bijv. op 2 geschat is, vraagt de product owner of deze story 2, 3 of meer of misschien toch minder is. Indien de uitkomst is dat het minder is, schrijf de waarde op achter het item, maar verplaats de hele regel dan ook meteen onder het vorige item. Zo blijft de lijst gerangschikt van boven naar beneden op meest tot minst inspanning vereiste items. Als het een gelijke waarde betreft als de vorige, laat dan gewoon staan, net als bij een hogere waarde. Herhaal deze stap net zolang alle items uit de lijst geschat zijn.

Het gaat om de discussie en niet om het schatten zelf. Liever een duidelijk sprint doel, dan een goede schatting die achteraf toch minder goed blijkt te zijn en geen gehaald doel.

 

Sprint planning met een gedistribueerd team

Mocht je deze lijst meteen willen gebruiken voor de (komende) sprint backlog, dan zou het verloop als volgt verder kunnen gaan:

  1.  Nu komt het ‘cadeautjes uitpakken’ deel voor de product owner. De lijst is nu gerangschikt op meest tot minst werk inspanning vereiste items. Dit moet de product owner nu gaan rangschikken op wat het eerst af moet, wat de hoogste prioriteit heeft. Het team mag dit actief toezien. Soms gebeurt het bijv. dat een developer opeens roept dat er een afhankelijkheid over het hoofd gezien is, wat invloed kan hebben op de prioriteit.
  2. Tel alle story points bij elkaar op van deze lijst. Neem vervolgens het gemiddelde van de afgelopen 3 sprints aan verbrande story points per sprint, de team velocity. Haal dan items onderaan de lijst weg, net zolang tot het totaal aantal story points van de lijst ten hoogste gelijk is aan de velocity die zojuist is uitgerekend. Verderop in dit artikel staat een tip over team velocity berekenen.
  3. Nu kan het team aan de slag met deel 2 van de Sprint planning: hoe is het developer team van plan de gekozen sprint backlog te realiseren. Werk het item opsplitsen in taken af van boven naar beneden: begin met de hoogste prioriteit items, zodat wanneer de timebox verlopen is, het team in ieder geval aan de slag kan gaan met de belangrijkste items.

Onbekende of onbetrouwbare team velocity 

Bij stap 2 tijdens de sprint planning van hierboven kan het zijn dat er geen bekende of betrouwbare team velocity is. Redenen kunnen onder meer zijn dat het team is aangepast, de roadmap omgegooid is, er nog geen 3 sprints gedaan om tot een minimaal acceptabel gemiddelde team velocity te komen.

Tip 1: Gebruik dan kennis die je hebt: bij geen sprints, laat de team velocity dan helemaal achterwege en kies een aantal waar het team zich goed bij voelt. Deze keuze komt van het developer team af, niet van de scrum master of product owner. Gebruik deze sprint als input voor de volgende sprint om tot een team velocity te komen. Advies is om van een team velocity te spreken wanneer het gemiddelde van de laatste drie sprints berekent kan worden.

Tip 2: Een meer berekende aanpak is de volgende. Reken het aantal uur uit dat het team beschikbaar is voor de komende sprint en deel dat door 2 (ga uit van een 50% effectief team). Ga vervolgens verder met het tweede deel van de sprint planning. Maak daarbij duidelijk dat het de bedoeling is dat iedere taak niet meer dan een halve werkdag in beslag mag nemen.

Tel vervolgens aan het einde van die sessie het aantal taken, vermenigvuldig dat totaal met 4 uur. Kom je op meer uren uit dan het aantal beschikbare uren, dan heeft het team teveel hooi op z’n vork genomen. Laat zoveel sprint backlog items vallen dat nodig is om onder het aantal beschikbare uren uit te komen.

Mocht blijken dat het team de sprint backlog eerder heeft afgewerkt dan de duur van de sprint, verhoog dan de effectiviteit naar een beter aansluitende percentage. Streef naar een team dat zit tussen de 70-75%, volgens de literatuur heb je dan een lekker lopend team. Boven de 90% wordt een team beschouwd als hyper productive.

Happy estimation!

More to explore

It’s how you say it!

The last couple of weeks I have noticed how often messages don’t come across as intended. This is not only destroying relationships

The autonomy and alignment experiment

See how people react when given a simple task with a combination of high or low autonomy and alignment. How does this make them feel? And how do they experience this?