5 redenen om de volgorde van items te wijzigen

Een Product Owner geeft zijn team 10 Story Cards (kaartjes met elk een User Story). De teamleden lezen ze en geven de vijfde en zesde kaart terug aan de Product Owner. Aan het einde van de Sprint levert het team de functionaliteit van kaart 1, 2, 3, 4 en 7 op. Er is echter nog niet begonnen met de taken op kaart 5 en 6.

Naar mijn mening is dat prima.

Een standaardaanbeveling bij agile methoden is dat het team in de volgorde aan de Backlog Items moet werken die de Product Owner bepaalt. Hoewel dat tot op zekere hoogte logisch is, maken goede agile teams regelmatig uitzonderingen op deze regel.

Er zijn veel goede redenen voor een team om de opgegeven volgorde niet aan te houden. Hier heb ik er een aantal opgesomd die als rechtvaardiging zouden moeten volstaan:

1) Synergie-effecten

Vaak zijn er synergie-effecten tussen de items bovenaan de Product Backlog. Terwijl een team bijvoorbeeld aan item nr. 3 werkt, zou het ook aan item nr. 6 mogen werken. Als twee items zich in hetzelfde deel van het systeem bevinden en sneller samen afgerond kunnen worden, zou de Product Owner dat ook moeten toestaan.

2) Afhankelijkheden

Een team besluit misschien dat item 4 belangrijker is dan items 5 en 6. Helaas kan er aan nr. 4 pas gewerkt worden als nr. 7 is afgerond. Zo'n afhankelijkheid is normaal gesproken voldoende reden om een team toe te staan af te wijken van de beoogde volgorde.

3) Beschikbaarheid van expertise

Een team zou misschien graag aan het op vier na belangrijkste item van de Product Owner willen werken, maar de juiste persoon daarvoor is helaas niet beschikbaar. Natuurlijk kan dit een teken zijn dat meer teamleden in staat zouden moeten zijn om cross-functioneel te werken – maar dat is eerder een langetermijnoplossing. Een kortetermijnoplossing zou zijn om gewoon aan andere items te werken totdat het teamlid met de benodigde vaardigheden weer beschikbaar is.

4) Het is interessanter

Oké, over dit punt valt te discussiëren. Ik zeg niet dat het team aan items nr. 1, 2, 3, 4 en dan aan nr. 600 zou moeten werken. Maar de items kiezen zoals in mijn voorbeeld (1, 2, 3, 4, 7) is prima, als het werk op die manier wat spannender wordt.

In sommige projecten stuiten teams af en toe op een hele reeks Product Backlog Items die niet echt veel plezier opleveren. Als een team zo nu en dan een item naar voren kan halen dat wat afwisseling biedt, kan dat een positief effect hebben op het moreel van de teamleden. En dat is weer goed voor de Product Owner.

Bonus: 4.1.) Het is interessanter voor stakeholders

Nu we het er toch over hebben: ik durf te beweren dat het ook prima is voor een team om de volgorde te veranderen als bepaalde items interessant zijn voor de Stakeholder.

Soms kan het een behoorlijke uitdaging zijn om alle belangrijke personen zover te krijgen dat ze deelnemen aan de Sprint Reviews. Het wordt extra lastig als de laatste Reviews nogal saai waren. De reden daarvoor kan de hoge prioriteit van bepaald werk zijn (bijv. belangrijke zaken die voor de stakeholders niet echt zichtbaar zijn).

In zo'n geval kan het slim zijn om het volgende Sprint Review een beetje meer aantrekkingskracht te geven. Als het team namelijk aan iets werkt wat de stakeholders interessant vinden, zullen ze ook eerder aan de meeting deelnemen.

5) Omvang

Mochten de voorgaande redenen je nog niet overtuigd hebben, dan heb ik de meest overtuigende reden voor het laatst bewaard. Deze bewijst dat elk team af en toe mag afwijken van de door de Product Owner bepaalde volgorde: een team mag bijvoorbeeld item nr. 5 overslaan als het te groot is. Dan pakt het team het volgende item dat qua omvang in de Sprint past.

Als dat niet zou mogen, zou het team alleen items 1, 2, 3 en 4 selecteren en dan stoppen. Dan zou mogelijk een aanzienlijk deel van de Sprint onbenut blijven. Natuurlijk zou het team op zijn minst een deel van item 5 kunnen afronden en dan een ander item oppakken. Maar dat is in veel gevallen niet bijzonder zinvol. Daarom zal het team op zijn minst af en toe afwijken van de oorspronkelijke volgorde.

Product Owners zijn niet perfect

Een perfecte Product Owner zou dit allemaal weten. Een perfecte Product Owner zou weten dat de eerste vier items in de backlog al zoveel database-gerelateerd werk betekenen, dat je niet nog zo'n item op positie 5 zet. Een perfecte Product Owner zou weten dat items 2 en 5 betrekking hebben op dezelfde Java-klasse en ze daarom bij het prioriteren zou samenvoegen.

De meeste Product Owners vinden het echter lastig om perfect te zijn. De beste oplossing is simpelweg de Product Backlog zo goed mogelijk te prioriteren en dan het team de fijnafstemming te laten doen.

Deze tekst is afkomstig uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.

agile100: Roger Martin

=> In februari 2021 spraken we met Roger L. Martin over zijn boek "When more is not Better".

Agile werken bij MAN

=> Hoe agile is MAN Truck & Bus SE en hoe werkt het agile werken in de automobielindustrie?