Meerdere product backlogs? Yes please!

In mijn tijd werkzaam als product owner voor Philips ben ik aanraking gekomen met SAFe. Onderdeel daarvan is het beheren van product backlogs op meerdere niveaus. Nu lees en hoor ik vaak meningen dat je scaling niet moet doen en SAFe al helemaal niet, omdat er facetten haaks op het agile gedachte goed staan. Dat zal vast waar zijn, maar dat vraagt naar mijn mening een grote mate van volwassenheid in het agile werken. Dat geldt voor vele van ons nog niet en zo ook niet voor mij en de organisaties waar ik tot nu toe werkzaam ben geweest. Ik heb dan ook het werken met product backlogs op meerdere niveaus erg nuttig ervaren en toegepast in mijn opdrachten na Philips. Lees meer

A product backlog should contain just about 50 items

An thought-provoking idea has rested in my mind for some time and I’m writing it down right now to get some feedback. Maybe I’m completely wrong, but that ‘ll be clear from the reactions.

I often see very large product backlogs with hundreds of items in them. The sheer size makes it very hard to keep the overview. The symptoms are then solved with ever-expanding structures with epics, features, themes etc. But the root-cause is the size, and I contend that it’s not wise to make the backlog so large.

And I think it is really not necessary to have a large backlog. It’s rather a remainder of a waterfall mentality.

A product backlog with 50 items is enough! And this is why:

The top of the backlog, the work for the coming 2-3 sprints, should contain small and clear items. In my experience most teams deliver 6-10 items per sprint, so that yields some 25 items at the top.

Below that, the items should not be that small. There should be larger items that can be sliced into small pieces later.

Slicing already now is not wise. It could be that we will not deliver this item. New, and more important items can emerge, the PO may down-prioritise these items. Maybe the client asks us to take new directions, or the team invents smarter technical solutions. Slicing the items too early is a form of waste. Having too many small items in the backlog can make us less agile. We don’t want to change direction because we have put so much time in the existing items already.

So, after the top 25 small items, there should be larger items in the backlog. If the top-items are all 1-8 story points in size, the items lower in the backlog should be 13-40 points in size, and lower still the items should be even bigger. So having only 50 items in the product backlog is enough to keep the team busy for a year or so.

Well, this is my theory. Any thoughts?

Een product backlog moet altijd maar ongeveer 50 items bevatten

Hierbij maar eens een provocerend blogje met een provocerende titel. Het is een idee dat bij mij al een poosje borrelt en dat ik maar eens opschrijf om er feedback op te krijgen. Misschien zit ik er wel helemaal naast, maar dat wordt dan wel duidelijk uit de reacties.

Ik zie vaak hele grote, lange product backlogs met honderden items erin, waarin men met grote moeite overzicht behoudt. Om dat overzicht te krijgen worden dan allerlei levels toegevoegd, thema’s, epics, stories, of nog meer niveaus.

Volgens mij is dat allemaal niet nodig, sterker nog, volgens mij is het fout en een teken van nog steeds behoorlijk waterval werken.

Een Product Backlog met 50 items is genoeg!

Dat zit zo.

De top van de backlog, het werk voor de komende 2 of 3 sprints, moet mooie kleine, heldere items bevatten. In mijn ervaring doen de meeste teams ongeveer 6-10 items per sprint, dus dat geeft de eerste 25 of zo items.

Daaronder hoeft het allemaal niet zo precies en zo klein te zijn. Het zijn grotere brokken die later wel in stukjes gehakt worden als ze bijna in een sprint worden opgepakt.

Nu al in stukjes hakken is niet slim. Het zou zomaar kunnen zijn dat we dit item helemaal niet gaan oppakken. De klant wil misschien een andere kant op, of we verzinnen een heel andere technische oplossing. Agile zijn betekent dat je zoveel mogelijk openstaat voor dit soort veranderingen. Alles vast helemaal opknippen en uitwerken zorgt ervoor dat je al snel denkt: “dit moeten we echt zo uitvoeren, daar is al zo veel voorbereiding in gestoken”.

Onder die 3 sprints met kleine items (zeg van 1-8 story points groot) komen dus grotere items. Rond sprint 3-5 in de backlog zijn ze nog niet zo heel groot, 13-21 punten groot. Maar daaronder zijn het grotere brokken, 40-100 punten groot.

De hele backlog van 50 items vertegenwoordigt dus werk voor een heel jaar. Maar vooraf uitwerken is een vorm van waterval denken.

Herkenbaar? Mee eens? Ik hoor jullie reacties graag!

Value points

André Heijstek, directeur van Valueminds:

‘De kosten van een user story worden in de regel ingeschat in story points, waarvoor we meestal de Fibonacci-reeks gebruiken (1,2,3,5,8, etc.). Maar hoe schat je de waarde van een user story in? Dit kan op dezelfde manier. De product owner kan samen met zijn stakeholders de inschatting maken met dezelfde Fibonacci reeks. Hiervoor kan je planning poker kaartjes gebruiken. Het kan natuurlijk ook met een andere set getallen. Ik zelf werk altijd met een reeks van 1 t/m 1000, waarbij 1000 het meest belangrijk is.

Als je de backlog hebt ingeschat op zowel de waarde als de kosten, dan is een deel van de prioritering van de backlog gemakkelijker geworden. Je kan dan per user story de prioriteit berekenen als business waarde/story points, bijvoorbeeld:

planning poker kaarten Valueminds

Stories zoals story 4 met veel waarde en weinig kosten kan je zo snel mogelijk oppakken. Stories met weinig waarde en veel kosten (story 3) kunnen van de backlog verwijderd worden. Natuurlijk is dit niet het enige wat de product owner mee moet nemen in de prioriteitsstelling. Technische afhankelijkheden tussen stories kunnen tot een andere volgorde leiden: je kan story 5 pas bouwen als story 13 eerst gebouwd is.

Daarnaast is het vaak ook slim om soortgelijke stories in 1 sprint bij elkaar op te pakken. Je krijgt dan een heldere sprint goal zoals: ‘in deze sprint doen we alle rapportage-stories.’

Het kan ook zijn dat je met stories op meerdere niveaus werkt, zoals thema’s, epics, etc. In dat geval moet je oppassen dat je maar op één niveau waardepunten toekent. Wat mij betreft is het laagste niveau (het niveau van de user stories) de plek waar je waarde zou moeten toekennen. Wanneer je dit niet doet, ga je dingen dubbel tellen. Ik kies voor het laagste niveau omdat ik van mening ben dat elke user story de waarde zou moeten hebben. Wanneer je punten op dit niveau gaat toekennen, dwingt het je ook om er zo over na te gaan denken.’

Volgorde van de backlog

André Heijstek, directeur van Valueminds:

‘De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder. De regel die het meest wordt gebruikt is dat de items op volgorde van waarde staan. Naar mijn mening is dat echter te beperkt. In mijn ideale situatie bepaalt een mix van de volgende factoren de volgorde van de backlog:

  • Technische afhankelijkheden. Er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.
  • Waarde. Spannende stories waar mogelijk ellende in zit moet relatief hoog op de lijst staan: fail fast is beter dan fail late.
  • Risico. De waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de Product Owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig).

Naast deze drie aspecten, komt er in de keuzes voor de komende sprint nog en aspect bij: wanneer de items waaraan in een sprint wordt gewerkt aan elkaar gerelateerd zijn, werkt dit veel prettiger. Dan krijg je zoiets als: ‘In sprint 4 doen we rapportage, in sprint 5 implementeren we het zoeken.’ Wil je dat het team meer focus krijgt en meer gaat samenwerken tijdens sprint? Stel dan een sprint goal!’

Hoe user stories snel inschatten?

André Heijstek, directeur van Valueminds:

‘Planning poker is een bekende techniek om de grootte van User Stories in te schatten. En het is een goede techniek. Maar als ik veel (30-100) stories snel moet inschatten, dan duurt pokeren me te lang.

Maar wanneer is het nuttig om een grote groep stories in te schatten? Je kan dit doen wanneer de Product Owner wil weten hoe lang het ongeveer gaat duren om een bepaald deel van zijn backlog te bouwen. Ook agile projecten moeten ten slotte de verwachtingen van stakeholders managen.

Mijn techniek voor het snel inschatten van user stories is als volgt. Ik print alle user stories uit op klein formaat (A5 of A6) en ik leg ze in een stapel op tafel. Vervolgens vraag ik aan het development team om deze stapels in drie kleinere stapels te verdelen: Klein, Midden en Groot. Ik zorg dat de Product Owner hierbij aanwezig is, zodat hij snel uit kan leggen wat de bedoeling is van de stories. Mijn ervaring is dat dit ongeveer een uur kost voor 70-100 stories.

Als het team dit heeft gedaan, vraag ik het development team om hetzelfde nog een keer te doen. Er ontstaan dan 9  stapeltjes, van Klein-Klein tot Groot-Groot. De tweede ronde kost veel minder tijd, vaak is een half uur voldoende. Alle 9 stapeltjes bevatten user stories die ongeveer even groot zijn, en krijgen dus allemaal dezelfde grootte (in uren of in story points, net wat h et team gewend is).

Heeft het team nog geen schattingsmethode gekozen? Dan is dit een goed moment om daarmee te starten! De stapel Klein-Klein krijgt 1 story point en dient als referentie voor de andere stapels. De stapel Midden-Klein wordt vergeleken met Klein-Klein. Zijn ze 2 keer zo groot? 3 keer? Elk stapeltje krijgt op deze manier heel snel een waarde in story points.

Heeft het team al wel een schattingsmethode gekozen? Dan kunnen bestaande stories als referentie gebruikt worden.

In de praktijk heb ik vaak gezien dat de stories vanaf Midden-Midden te groot zijn om echt mee te werken. Het zijn geen stories meer maar epics. In dat geval moet er later nog gesplitst worden in kleinere stories. Al met al ben je ongeveer 2 uur kwijt om een hele backlog in te schatten.’