Backlog refinement – theory and tips

The activity in Scrum that causes most confusion is the backlog refinement. The scrum guide does not treat refinement as an event, like sprint planning or the retrospective. So it does not have a clear timeslot in the sprint. The scrum guide treats it as an activity that needs to take place, but leaves it up to you how to perform this.

The literal text about backlog refinement in scrum is:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

So, the goal of backlog refinement is that product owner and team work together towards a good product backlog.

In the picture below I give a sketch showing the timeline of a new idea to working software, which may help to clarify the refinement process.

Backlog refinement Andre Heijstek Agileminds Valueminds

A new idea starts with a stakeholder. This can be a customer with an idea or complaint, or someone from “the business” with a smart idea, or a developer with a technical suggestion. These ideas should be given to the product owner.

The meeting where this idea is discussed with the PO is the very first backlog refinement. Maybe it is just two persons talking with each other, but the idea gets refined a bit already. If the PO likes the idea, it is placed on the product backlog. You could call this part of the process the “business refinement”.

Next, the idea should be discussed with the development team. They should get a clear picture about the item that needs to be developed. They should also estimate how much work it is, so the PO can take an informed decision about whether or not to develop this. Do the expected benefits outweigh the expected costs?

You could do this refinement session with the whole development team, but you can also start with subset of the team. In this way you can develop this idea into something better without spending the time of a lot of people. You can also invite stakeholders to this meeting if that will lead to a better clarification. You could call this meeting a pre-refinement, or prefinement, if you want.

If the idea is clear enough, you can have a refinement session with the whole team, so everybody will share the same picture. This is the “real refinement” session, where you will also do the estimation. If necessary, multiple refinement sessions can to be conducted until the idea is really clear.

After refinement, items can be picked up by a team in a sprint planning session. If the refinement has been done properly, the first part of sprint planning is easy. Just pick up the right amount of backlog items where the sum of the estimates matches your planned velocity. After this, sprint planning II remains, where you do detailed design on the selected items and add technical tasks.

It could happen that there still is a need for additional clarification during sprint execution. If this is just about minor details, that is perfectly OK. You could call this the after-refinement.

Hopefully this clarifies the refinement activity a bit. Any questions or comments? Please let me know.

Story point liniaal

Story point lineaal Andre Heijstek André Heijstek, directeur van Valueminds:

‘Een van de taken in de refinement is het inschatten van user stories. Dat schatten hoort echt bij de refinement. Sommigen beginnen hier pas mee in de planning, maar wat mij betreft is dat te laat. Dit is, omdat wanneer stories al zijn ingeschat, het makkelijker is voor de product owner om gemakkelijk de juste hoeveelheid stories voor een sprint aan te bieden in de planning.

We schatten de stories natuurlijk met planning poker. Ik zal niet herhalen wat daar al allemaal over is geschreven. Om goed te kunnen pokeren heb je een baseline nodig. Als je weet wat een ‘1’ is, dan kan je alle stories daarmee vergelijken en inschatten. Deze is twee keer zo groot, die vijf keer, etc.

Ik vind zelf een baseline met alleen de ‘1’ te mager. Daarom maak ik voor mijn team graag een story point liniaal waarin ik voor diverse getallen uit de pokerset (1, 2, 3, 5, 8, 13, …) een paar voorbeeldstories in opneem.

Schatten wordt nu een stuk gemakkelijker. Je houdt de story naast de liniaal en je vergelijkt: is hij groter dan de stories die we eerder als drie hebben ingeschat, maar kleiner dan de achten? Dan moet dit wel een vijf zijn.

Mijn ervaring is dat als teams hier twee meetings mee hebben gewerkt dat het dan gesneden koek is. Als scrum master zorg ik er altijd voor dat ik een paar kopieen van de liniaal bij me heb als we de backlog refinement doen. Wanneer de discussie over de story is afgerond stel ik de vraag: “Kunnen we al pokeren?”. Als dit het geval is, pakt iedereen zijn kaarten, vergelijkt nog even met de liniaal, legt de kaarten op tafel en het pokeren kan beginnen.’

Backlog refinement, hoe zit dat nou precies?

Andre Heijstek, directeur van Valueminds:

‘Een van de activiteiten in Scrum waar het meeste onduidelijkheid over is, is toch wel de backlog refinement. Door de scrum guide wordt het backlog refinement niet behandelt als een meeting zoals bij de sprint planning of de retrospective wel gebeurd. De meetings sprint planning en de retrospective hebben een duidelijke plaats aan het begin of aan het einde van de sprint. Maar de backlog refinement (verder: refinement) heeft geen duidelijke plaats in de sprint en wordt dus wat anders behandeld.

Wanneer je de tekst letterlijk uit de scrum guide haalt, staat er het volgende: ‘Product Backlog verfijning (“Refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog verfijning worden items beoordeeld en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog Items kunnen op elk moment worden bijgewerkt door de Product Owner of naar de Product Owner’s eigen beoordeling.’

Wat we hier uit kunnen halen is dat het doel van de refinement is dat het team en de product owner gezamenlijk werken aan een goede backlog. Hier onder staat de tijdlijn van een nieuw idee naar werkende software, om dit werk wat duidelijker te maken.

Backlog refinement Andre Heijstek Agileminds Valueminds

Een nieuw idee start bij een stakeholder. Dit kan een klant zijn, die met een idee of een klacht komt, of misschien is het wel iemand van de business die een slim idee heeft, of een developer die vanuit de techniek met een suggestie komt. De product owner beheert de backlog, waarop elk item dat opgepakt gaat worden door het team staat. Wanneer de stakeholder een idee heeft, moet deze in gesprek gaan met de product owner.

Eigenlijk is dit gesprek de eerste backlog refinement die plaatsvindt. Misschien zijn hier alleen maar de product owner en de stakeholder met elkaar in gesprek. Als het goed is, ontstaat er uit dit gesprek een helderder beeld van het idee. Dit kan dan op de product backlog geplaatst worden: je zou dit business refinement kunnen noemen.

Nadat de business refinement heeft plaatsgevonden, moet dit idee met het development team besproken worden. Zij moeten helder krijgen wat er ontwikkeld moet worden, en ze moeten ook een inschatting maken zodat de product owner een geïnformeerde beslissing kan nemen of zij dit item wel of niet wil laten ontwikkelen. Je kan deze refinement met het hele team, maar je kan het ook doen met een deel van het team, sommigen noemen dit een pre-refinement of prefinement. Daarnaast kan je ook de stakeholders uitnodigen voor de prefinement, zodat hij/zij het idee kan uitleggen.

In sommige gevallen is een idee al behoorlijk duidelijk en kan de product owner bijna zeker van zijn dat dit idee zo snel mogelijk ontwikkeld gaat worden. In dat geval kan je een refinement met het hele team houden. Wanneer het idee nog vaag is, is het verstandig om dit niet met het hele team, maar met een deel van het team te bespreken. Waarom de tijd van iedereen inzetten op een idee dat de discussie misschien niet overleeft?

Wat in ieder geval nog moet gebeuren na de prefinement is een ‘echte’ refinement. Zo is het hele team betrokken bij de schatting van het item en begrijpen ze het item. Als het nodig is kunnen meerdere refinement sessies worden gehouden voor één item, totdat deze helemaal duidelijk is.

Tijdens de refinement worden items geschat. Items die door de refinement discussies helder zijn geworden, kunnen ingeschat worden en zijn klaar om in een volgende sprint opgepakt te worden. Het oppakken van deze items gebeurd in de sprint planning meeting. Wanneer je voorafgaand aan deze meeting een goede refinement hebt gehad, is het eerste deel van deze meeting heel eenvoudig. Je kent je velocity (bijvoorbeeld dertig punten), en je selecteert items ter waarde van 30 punten. De product owner heeft hier een belangrijke stem in. Zij bepaalt de prioriteit van de items en dus de volgorde van de backlog. Daarnaast suggereert zij een sprint goal waar stories bij gekozen kunnen worden. Naast de product owner hebben ook de developers hier een stem in. Soms is er winst te behalen door soortgelijke  items als groep op te pakken. Of er is een technische reden om items in een bepaalde volgorde op te pakken.

Na het kiezen van de stories blijft het tweede deel van de sprint planning over, waar de technische taken worden bedacht om de stories te realiseren. Het zou kunnen dat er tijdens de sprint toch nog wat kleine onduidelijkheiden naar boven komen. In afstemming met de product owner kunnen deze verhelderd worden. Dit zou je after-refinement kunnen noemen.’

Waarom gebruiken we Story points?

 André Heijstek, directeur van Valueminds:

‘We gebruiken vaak story points als manier om elementen in te schatten in Scrum projecten. Waarom gebruiken we ze, en waarom zouden we story points gebruiken om iets in te schatten, als we dit ook met uren kunnen doen?

Om die vraag te kunnen beantwoorden, moeten we eerst even kijken naar het concept velocity. Wanneer je goede story points hebt, kan dit namelijk zorgen voor een waardevolle definitie van velocity.  Laten we analogie gebruiken om dit te illustreren:

Stel, je plant een vakantie met de auto vanaf Gouda (waar ik toevallig woon), naar Nice in Frankrijk. Google Maps laat meteen zien dat de hele trip 1351 KM is. Als ik de duur van de trip snel wil inschatten, doe ik dit als volgt:

Ik schat in dat de gemiddelde velocity 100 KM per uur is (normaal gesproken rij ik een beetje sneller, maar de ervaring leert mij dat je vaak word gehinderd op de weg, en ik niet veel sneller ga dan dit gemiddelde).

De totale tijd van de trip zal dus 13,5 uur duren. Laten we daar nog twee uur rust aan toevoegen, en we kunnen de tijd van aankomst inschatten.

We hebben nu dus een plan voor het project, we weten de totale grootte (1351 KM) en we hebben een tijd geschat voor de duur van het project (15,5 uur). Tijdens het project willen we onze progressie meten.

Het meten van progressie in uren is niet slim. Als er wegwerkzaamheden zijn rondom Rotterdam en ik sta 2 uur lang stil, is mijn progressie geschat in uren 2 uur, maar mijn echte progressie bijna niks. Wanneer je progressie in uren wil meten, zal dit me niet helpen om mijn tijd van aankomst te herschatten (tenzij alles precies volgens plan gaat).

De enige manier om op een juiste manier progressie te meten, is door de resultaten te meten. We kunnen dit doen door het aantal kilometers op het dashboard te bekijken, maar dat voelt wel heel erg als micromanagement. Je kan niet altijd naar het dashboard kijken: je moet ook het verkeer in de gaten houden.

Een veel betere manier is om de mijlpalen van de afstand te meten:

Mijlpaal Afstand (km) Duur in uren, cumulatief
Antwerpen 100 1
Brussel 150 1,5
Luxemburg 350 3,5
Pauze 4,5
Nancy 500 6
Dijon 700 8
Lyon 900 10
Pauze 11
Orange 1100 13
Marseille 1200 14
Nice 1350 15,5

Let op het volgende:

  1. de mijlpalen zijn niet allemaal precies van dezelfde afstand. Het zou fijn zijn als alle grote steden op mijn trip precies op 100 km afstand van elkaar liggen, maar dat is natuurlijk niet realistisch.
  2. Mijn schattingen van de afstand zijn niet exact, maar afgerond op 50 km. Nog exactere schattingen zijn niet nodig. Wanneer ik aan het rijden ben, weet ik nooit precies of ik Nancy heb bereikt of niet. Ik zal bijvoorbeeld eerst langs de afslag noord-Nancy komen, daarna door het centrum rijden en tot slot door zuid-Nancy rijden. Wanneer ik een van deze afslagen op ongeveer 6 uur na mijn vertrek bereik, weet ik dat ik nog steeds op schema lig. Het exact inschatten van wanneer ik bepaalde plekken heb bereikt zal er alleen maar voor zorgen dat ik mijn trip ga micromanagen en ga denken ‘ik ben drie minuten te laat!’, waardoor ik word afgeleid van de échte progressie die ik maak.

Laten we dit nu terugbrengen naar software projecten.

De velocity is het gemiddelde aantal van story points die een team kan opbrengen in een sprint (gelijk aan mijn gemiddelde snelheid van 100 KM per uur). Een story point is een indicatie van de grootte of de duur van de taak die we in een sprint kunnen opleveren. Een story moet klein genoeg zijn om met het team verschillende mijlpalen te behalen tijdens de sprint om onze progressie te meten. Mijn persoonlijke voorkeur is dat een sprint  6-10 stories heeft.

Wanneer je minder stories per sprint gebruikt (zeker wanneer het er minder dan 3 zijn), gaat dit gepaard met een aantal nadelen:

  • Ik kan niet in detail voorspellen of ik mijn doelen behaal, die ik had van te voren had gepland.
  • Er is een goede kans dat de laatste story in deze sprint niet volledig wordt opgeleverd. Wanneer dat gebeurd, heeft 50% of 33% van mijn sprint gefaald. Dat is een slecht resultaat. Wanneer ik 10 stories in de sprint heb, en ik heb de laatste niet gehaald, heb ik een resultaat van 90%. Dit is nog steeds niet perfect, maar wel een goed resultaat.

Meer stories betekent meer administratie, en we hebben hier natuurlijk allemaal een hekel aan.

Dus, waarom gebruiken we story points?

  • We willen onze business value (story points) meten, niet onze kosten (uren). Het meten van kosten is zinloos, want kosten worden hoger door tijd (ons team zit op z’n plaats, hun uren worden gebruikt, hun salaris wordt betaald) losstaand van welke progressie er is gemaakt.
  • Het meten van relatieve waarden (is deze taak twee keer zo groot als die kleine taak?) is veel makkelijker voor mensen om in te schatten.
  • Story points zorgen voor een waardevolle indicatie van de velocity. Deze wordt groter wanneer we leren om slimmer te werken.
  • De velocity zal alle typische afleidingen bevatten (koffie halen, standaard meetings), zonder dat we deze apart moeten administreren, dus minder bureaucratie.’

Hoe kan ik veel User Stories snel inschatten?

André Heijstek, directeur van Valueminds

‘Een bekende techniek om de grootte van een User Story in te schatten is natuurlijk planning poker. En dit is een goede techniek. Maar pokeren duurt me te lang als ik veel (30-100) stories moet inschatten.

Maar wanneer is het nuttig om een grote groep stories in te schatten? Bijvoorbeeld wanneer de Product Owner wil weten hoe lang het ongeveer gaat duren om een bepaald deel van zijn backlog te bouwen. Zelfs agile projecten moeten uiteindelijk de verwachtingen van stakeholders managen.

Ik gebruik hiervoor de volgende techniek: ik print alle user stories uit op een klein formaat (A5 of A6) en ik leg ze in een stapel op tafel. Daarna vraag ik aan de ontwikkelaars of zij deze stapels in drie stapels kunnen verdelen: Klein, Midden en Groot. Belangrijk hiervoor is dat de Product Owner aanwezig is om snel uit te leggen wat de bedoeling is van de stories. In mijn ervaring duurt dit alles ongeveer een uur voor 70 – 100 stories.

Wanneer dit klaar is, vraag ik het development team om hetzelfde nog eens te doen. Er ontstaan dan 9 stapeltjes: van Klein-Klein tot Groot-Groot. Deze tweede ronde kost een stuk minder tijd, vaak niet langer dan een half uur. De negen stapels bevatten user stories die ongeveer even groot zijn. Deze worden geschat in story points of in uren, net waar het team aan gewend is.

Heeft je team nog geen schattingsmethode? Dan is dit een prima moment om te starten! De stapel Klein-Klein krijgt 1 story point en dient als referentie voor de andere stapels. Daarna komt de stapel Midden-Klein, die wordt vergeleken met de stapel Klein-Klein. Zijn ze twee keer zo groot? Of vijf keer? Op deze manier krijgt elk stapeltje een waarde in story points.

Je kan bestaande stories als referentie gebruiken om nieuwe stories in te schatten. De stories vanaf Midden-Midden zijn in de meeste gevallen te groot om echt mee te werken. Dan worden het epics in plaats van stories. Deze moeten later nog gesplitst worden in kleinere stories. Het kost in totaal ongeveer 2 uur werk om een hele backlog in te schatten.’