Productbacklog - Wat is het en hoe maak ik er een aan?

Een agile backlog met goede prioriteiten maakt niet alleen release- en iteratieplanning eenvoudiger, het maakt ook alle dingen duidelijk waar je team tijd aan wil besteden, inclusief intern werk dat de klant nooit zal merken. Dit helpt verwachtingen te scheppen bij belanghebbenden en andere teams, vooral wanneer ze je extra werk opleveren, en maakt engineeringtijd een vast asset.

Een productbacklog is een lijst met werk op basis van prioriteit voor het ontwikkelteam, gebaseerd op de productroadmap en de bijbehorende vereisten. De belangrijkste items worden bovenaan de productbacklog weergegeven, zodat het team weet wat het als eerste moet leveren. Het ontwikkelteam werkt de backlog niet door in het tempo van de producteigenaar en de producteigenaar pusht geen werk naar het ontwikkelingsteam. In plaats daarvan haalt het ontwikkelteam werk op uit de productbacklog omdat er capaciteit voor is, hetzij continu (Kanban) of door iteratie (Scrum).

De roadmap en vereisten van een team vormen de basis voor de productbacklog. Roadmap-initiatieven vallen uiteen in verschillende epics, en elk epic heeft verschillende vereisten en userstory's. Laten we eens kijken naar de roadmap voor een fictief product genaamd Teams in Space.

Aangezien de Teams in Space-website het eerste initiatief in de roadmap is, willen we dat initiatief opsplitsen in epics (hier weergegeven in groen, blauw en groenblauw) en userstory's voor elk van die epics.

De producteigenaar organiseert vervolgens elk van de userstory's in één lijst voor het ontwikkelteam. De producteigenaar kan ervoor kiezen om eerst een complete epic te leveren (links). Of het kan belangrijker zijn voor het programma om het boeken van een vlucht met korting te testen waarvoor story's uit verschillende epics nodig zijn (rechts). Zie beide voorbeelden hieronder.

Wat kan de prioritering van een producteigenaar beïnvloeden?

• Prioriteit van een klant
• Urgentie om feedback te krijgen
• Relatieve implementatieproblemen
• Symbiotische relaties tussen werkitems (bijv. B is makkelijker als we eerst A doen)

Hoewel de producteigenaar de taak heeft om de backlog te prioriteren, gebeurt dit niet in een vacuüm. Effectieve producteigenaren vragen input en feedback van klanten, ontwerpers en het ontwikkelteam om ieders werklast en de productlevering te optimaliseren.

Zodra de productbacklog is opgebouwd, is het belangrijk om deze regelmatig te onderhouden om gelijke tred te houden met het programma. Producteigenaren moeten de backlog vóór elke iteratieplanningmeeting bekijken om ervoor te zorgen dat de prioritering correct is en feedback van de laatste iteratie is opgenomen. Regelmatige beoordeling van de backlog wordt vaak 'backlog-grooming' genoemd in agile omgevingen (sommigen gebruiken de term bakclogverfijning).

Zodra de backlog groter wordt, moeten producteigenaren de backlog groeperen in items op korte en lange termijn. Items op korte termijn moeten volledig worden uitgewerkt, voordat ze als zodanig worden gelabeld. Dit betekent dat volledige userstory's zijn opgesteld, samenwerking met ontwerp en ontwikkeling is uitgezocht en schattingen van ontwikkeling zijn gemaakt. Items op langere termijn kunnen een beetje vaag blijven, hoewel het een goed idee is om een ruwe schatting van het ontwikkelingsteam te krijgen om ze te helpen prioriteren. Het sleutelwoord hier is 'ruw': schattingen veranderen zodra het team die items op langere termijn volledig begrijpt en eraan begint te werken.

De backlog dient als verbinding tussen de producteigenaar en het ontwikkelteam. Het staat de producteigenaar vrij om op elk moment werkzaamheden in de backlog opnieuw te prioriteren vanwege feedback van klanten, het verfijnen van schattingen en nieuwe vereisten. Als het werk eenmaal aan de gang is, moet je wijzigingen tot een minimum beperken, aangezien ze het ontwikkelteam verstoren en de focus, de flow en het moreel beïnvloeden.

Antipatronen om op te letten

• De producteigenaar prioriteert de backlog aan het begin van het project, maar past deze niet aan naarmate er feedback binnenkomt van ontwikkelaars en belanghebbenden.
• Het team beperkt items op de backlog tot items die klantgericht zijn.
• De backlog wordt bewaard als een document dat lokaal wordt opgeslagen en niet vaak wordt gedeeld, waardoor geïnteresseerde partijen geen updates kunnen krijgen.

Slimme producteigenaren houden de productbacklog van hun programma rigoureus bij, waardoor het een betrouwbaar en deelbaar overzicht van de werkitems voor een project is.

Belanghebbenden zullen prioriteiten uitdagen, en dat is een goede zaak. Door discussie te bevorderen over wat belangrijk is, worden ieders prioriteiten gesynchroniseerd. Deze discussies bevorderen een cultuur van groepsprioritering, zodat iedereen dezelfde mentaliteit over het programma deelt.

Onthoud dat de productbacklog ook als basis dient voor iteratieplanning. Alle werkitems moeten in de backlog worden opgenomen: userstory's, bugs, ontwerpwijzigingen, technische schulden, verzoeken van klanten, actie-items uit de retrospective enz. Op deze manier kan je team ervoor zorgen dat de werkitems van iedereen worden opgenomen in de algemene discussie voor elke iteratie. Teamleden kunnen vervolgens afwegingen maken met de producteigenaar voordat ze een iteratie starten met volledige kennis van alles wat er moet gebeuren.