De productbacklog: jouw ultieme takenlijst

Een gezonde #ProductBacklog lijkt veel op een gezond mens: verzorgd, georganiseerd en met een open mind.

Dan Radigan Door Dan Radigan
Onderwerpen zoeken

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.

Wat is een productbacklog?

Een productbacklog is een lijst met werk op basis van prioriteit voor het ontwikkelteam, gebaseerd op de roadmap en de vereisten daarvan. 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).

Tip van pro's:

Bewaar alles in één issuetracker: gebruik niet meerdere systemen om bugs, vereisten en technische werkitems op te sporen. Als het werk betreft voor het ontwikkelingsteam, bewaar het dan in één backlog.

Begin met de twee 'R's'

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.

Agile roadmap | Atlassian agile coach

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.

Agile initiatieven en epics | Atlassian agile coach

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.

Agile epics en story's | Atlassian agile coach

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.

De backlog gezond houden

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" achterstallige verzorging genoemd" in behendige kringen (sommigen gebruiken de term achterstallige verfijning).

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.

Tip van pro's:

Zodra de backlog verder groeit dan de capaciteit van het team op lange termijn, is het oké om issues af te sluiten die het team nooit zal bereiken. Markeer die issues met een specifieke beslissing zoals 'buiten bereik' in de issue tracker van het team om deze later voor onderzoek te gebruiken.

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.

Hoe houden productbacklogs het team agile?

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.

Tip van pro's:

Producteigenaren bepalen de prioriteit van werkitems in de backlog, terwijl het ontwikkelteam de doorvoersnelheid door de backlog bepaalt. Dit kan een gespannen relatie opleveren voor nieuwe producteigenaren die werk naar het team willen 'pushen'. Lees meer in ons artikel over limieten en doorstroming van werk in uitvoering.