Vrijwel ieder agile project maakt gebruik van een product backlog. In de officiële Scrum Guide is de product backlog omschreven als een lijst met alle kenmerken, functies, requirements, verbeteringen en foutherstel die samen de veranderingen beschrijven die aan het product zullen worden gedaan in toekomstige releases. De items op de product backlog worden meestal weergegeven als user stories.
Een product backlog is niet hetzelfde als een traditionele lijst met SMART-requirements. De belangrijkste kenmerken van een goede product backlog heeft Mike Cohn samengevat in het acroniem DEEP.
DEEP staat voor:
Detailed appropriately
De items op de product backlog hebben het juiste detailniveau.
De user stories die in de komende sprint geïmplementeerd worden, zijn klein en de user stories die voorlopig nog niet aan de beurt zijn, zijn veel groter. Het is onverstandig om allemaal gedetailleerde user stories op de product backlog te zetten. Dat is lastig te managen, is onoverzichtelijk, leidt tot veel rework en het inschatten en prioriteren van al die kleine user stories kost veel tijd. Kortom, te veel details op de product backlog is verspilling van tijd en energie (waste).
Het advies is dan ook: Add details at the last responsible moment.
Estimated
Voor ieder item op de product backlog is de omvang ingeschat.
Het gaat om een relatieve schatting; niet om de tijd die nodig is om een user story te implementeren. Het team schat in hoe groot een user story is in vergelijking met een aantal referentie user stories. Bijvoorbeeld anderhalf keer zo groot, tien keer zo groot. Ieder user story krijgt hiertoe een aantal punten. Aangezien deze punten relatief zijn en daardoor geen grootheid hebben, worden ze meestal aangeduid als story points.
De schattingen zijn belangrijk omdat de product backlog onder andere dient als planningstool. In de product backlog is namelijk eenvoudig aan te geven welke user stories in een sprint en in een release meegenomen kunnen worden.
Emergent
De product backlog evalueert.
De product backlog is dynamisch in de zin dat deze voortdurend verandert om te kunnen weerspiegelen wat er nodig is om het product waardevol, concurrerend en beter te maken. De product backlog is daarom nooit af. De producteigenaar en het team passen de user stories, de prioriteiten en de schattingen voortdurend aan aan de laatste inzichten. Die inzichten veranderen doordat je steeds meer te weten komt over het product, de gebruikers, de omgeving en de technologie en doordat de mening en behoeften van de stakeholders aan voortschrijdend inzicht onderhevig zijn.
Prioritized
De items op de product backlog staan in volgorde van prioriteit.
De user story met de hoogste prioriteit staat bovenaan en wordt als eerste geïmplementeerd. De product owner kent de prioriteiten toe, maar laat zich adviseren door stakeholders uit de business en door het team. Aspecten die meespelen bij het prioriteren van de user stories zijn: minimum marketable features, business value, risico’s en afhankelijkheden.
Prioritering is essentieel voor het leveren van zo veel mogelijk business value. De producteigenaar is verantwoordelijk voor het maximeren van de return on investment (roi).
Wat mijn zorg is in dit verhaal is het slotakkoord over de prioriteiten. Zeker in een ontwikkelingstraject zouden de bouwers en technische argumenten de doorslag moeten geven in de volgorde en dat lees ik niet terug. Als productowners en de buisiness de prioriteiten gaan bepalen dat lijkt me niet verstandig. De kwaliteit van de software zou voorop moeten staan en dat vraagt soms om een andere volgorde. Vind zelfs dat de bussiness hier helemaal niet leidend in zouden moeten zijn hoe belangrijk die ook is.
Prima hulp om met DEEP bij de backlog items een Scrum/Agile werkwijze ook de requirements op het juiste niveau en moment vastgelegd te krijgen! En qua prioriteiten is het zeker van groot belang dat de Product Owner de juiste volgorde bepaald, immers het is zijn geld wat wordt besteed en hij kan het beste de baten inschatten. Een backlog item (b.v. user stories) is ook geen IT-ding, maar gaan over resultaat, business value en wie er wat aan heeft. Vanuit een (IT) team mag je daar best inhoudelijk goede vragen over stellen (om het te begrijpen), maar of de ene business reden belangrijker is dan de andere is echt iets voor de Business/Product owner.
Beste Nicole, Bedankt voor de herhaling van de mening van Mike Cohn. Maar wat is nu precies jouw mening over DEEP?
Persoonlijk maak ik me nogal zorgen over de tweede E van DEEP, zeker met jouw toelichting dat de Product Backlog nooit af is.
Mijn ervaring is dat Agile projecten nogal eens het pad onderweg kwijtraken, doelen bijstellen en Business Cases niet waar maken. Eén van oorzaken – naar mijn mening – is dat de Product Backlog gevuld is met allerlei zaken die helemaal niet bijdragen aan echt oplossen van het onderliggende business probleem.
In tegenstelling tot Louis ben ik echter wel heel blij met de laatste zin!
@Alexander Vermeulen Over die laatste zin. Geen misverstand, de opdrachtgever/business is datgene waar het om draait en die zo goed mogelijk bediend moet worden waarbij ict ondersteunend en een middel is en geen doel. Daar gaat het me niet om, het gaat me erom dat ook vanuit de business ict trajecten tot in detail begeleid worden. Ik denk dat voor kwaliteit de ict afdeling alle ruimte en de tijd moet hebben.
@Marcel Mars Natuurlijk geeft de business prioriteiten aan. Ik neem aan dat je dat van te voren al wat voor ogen hebt. Dat is geen waan van de dag. Zou de rol van productowner/gebruiker/klant liever zien als iemand waarmee de ict oplossers de functionele specs boven water krijgen. En geen rol spelen in het bouwen op zich.
@Louis Kossen. We zijn het gelukkig eens dat de Business over het Wat gaat en het ontwikkelteam over het Hoe. Zoals vaker praat je snel langs elkaar heen.
Zo ook op het vlak van Kwaliteit. Ik ben er stellig van overtuigd dat ook de Business de Kwaliteit bepaald; om het vergelijk maar weer te pakken, heeft de business een klein stadsauto’t, een gezinsauto of een pick-up truck nodig. Misschien is een “weggooi” applicatie die over een jaar weer vervangen wordt voldoende? Misschien moet het de komende twee decennia overleven?