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.

Maar wat houdt het hebben van meerdere product backlogs nu precies in? Als je met één product backlog werkt, zou je backlog er als onderstaand uit moeten zien. Geprioriteerd met bovenaan kleine stories (max 1 spirnt) met voldoende informatie voor de scrum teams om op te pakken. De stories onderaan zijn nog te groot en de mate van detail is niet voldoende voor scrum teams om de story op te pakken. Dat is ook niet nodig omdat aan deze stories nog niet gewerkt wordt door de teams, maar door deze al wel toe te voegen, weerspiegelt de product backlog de lange termijn visie van dat moment.

Eén product backlog

Als je meerdere product backlogs wilt hanteren, splits je bovenstaande backlog op naar meerdere backlogs. In mijn voorbeeld wordt de product backlog opgesplitst naar drie niveaus:

Product backlog vertaald naar meerdere niveaus

In bovenstaand voorbeeld is de eerste product backlog vertaald naar de lichtere delen van de bovenstaande backlogs. Wat je waarschijnlijk al wel opvalt is dat de backlogs in een Kanban vorm gegoten zijn. De lichte delen zijn de processtappen / statussen waarin de backlog items uitgewerkt worden totdat de items voldoende informatie bevat voor het gerelateerde niveau. De donkere delen zijn voor de backlog items die op het onderliggende niveau zijn geplaatst en geven ook hier de status van ieder backlog item weer. Gecombineerd geeft iedere backlog het proces weer, van begin (DoR) tot eind (DoD), waar een backlog item doorheen moet.

Ik gebruik bewust geen termen voor iedere backlog omdat dit voor iedere organisatie anders kan zijn, net zoals het aantal niveaus wat gebruikt wordt. Hetzelfde geldt voor de grote van een backlog item en de te gebruiken statussen op de backlogs.

Op het hoogste niveau backlog komen alle nieuwe grote brokken werk binnen. Op dit moment is het belangrijk dat voor ieder item de business waarde bekend is (technische verbeteringen en interne projecten hebben ook business waarde!) en een eerste inschatting van de impact op de scrum teams. Rollen waaraan je moet denken die hierbij betrokken zijn; product management, chief product owner, lead architecten, lead UX. Deze backlog zou dus een duidelijk inzicht moeten geven in de lange termijn visie van de organisatie. Als er ergens binnen de organisatie een ander beeld leeft, zal dat interessante discussies opleveren.

Zodra een item akkoord is bevonden en voldoende voorbereid, kan deze vertaald worden naar de onderliggende backlog . Het item op de bovenliggende backlog verhuist naar het donkere gedeelde zodat de voortgang bewaakt kan worden, totdat alle onderliggende items zijn afgerond. Op de onderliggende backlog worden de items weer iets verder uitgewerkt en opgesplitst naar kleinere items (slicing). Het three amigo principe, geeft een goede indicatie van betrokkenen en niveau van detail wat op dit moment gewenst is. De relatie tussen beide backlogs is niet per definitie 1:1. Er kunnen meerder onderliggende backlogs aanwezig zijn. Van je hoogste niveau mag er echter maar één aanwezig zijn.

Het laagste niveau geeft de backlogs op scrum team niveau weer. In het lichte deel vind voor alle items het voorbereidend werk van het scrum team plaats (e.g. refinenemt, onderzoek, slicing). Het donkere deel is de sprint backlog van het team voor de huidige sprint. De relatie tussen deze backlogs, blauw en geel, is hetzelfde als de relatie tussen roze en blauw, 1:n en items overgenomen op de gele backlog(s) verhuizen naar het donkere gedeelte van de blauwe backlog voor het bewaken van de voortgang.

De grootste voordelen die ik heb ervaren met deze manier van werken zijn

  • Al het werk wat gedaan wordt, is terug te leiden naar de visie van de organisatie en kan eenvoudig gecommuniceerd worden naar stakeholders en de scrum teams. Natuurlijk pakken teams wel eens werk op wat niet direct terug is te leiden, maar dit zou maar een bepaald aantal story points per sprint mogen zijn.
  • Verschillende rollen zijn op verschillende momenten betrokken bij een backlog item. Daarnaast vergt een backlog item constant aandacht, ongeacht deze niet hoog op de product backlog staat. Door de product backlog op te splitsen is de voortgang op zowel korte als lange termijn voor iedereen inzichtelijk en kan deze continu bewaakt worden.
  • Ondanks dat een story op zich al iets van waarde op moeten leveren, zit de grootste waarde in het opleveren van alle stories van een backlog item op de hogere niveaus. Nu dit inzichtelijk is, kan je dit eenvoudig meenemen in de prioritering van backlog items.
  • De backlogs zijn een weergave van het huidige proces van de gehele ontwikkel organisatie. Doordat dit in kaart is gebracht en de voortgang wordt bewaakt, kan het proces gericht worden verbeterd, zodat items sneller op kunnen worden geleverd.

Moet iedereen nu overstappen naar deze product backlog structuur? Nee, dat zeker niet. Als je werkzaam bent in een omgeving waar meerdere scrum teams werken aan hetzelfde product / visie en bovenstaande punten op dit moment ontbreken, dan is het zeker het proberen waard. Zoals eerder gezegd ben je vrij volledig vrij in de opzet (m.u.v. het laagste niveau. Daar mag de grote van een item max. één sprint zijn). Om een begin te maken, is mijn advies om niet te veel tijd te stoppen in het bedenken hoe je het aan wilt gaan pakken. Gebruik de huidige processen zoveel mogelijk voor de eerste opzet en blijf deze continu verbeteren. Indien het huidige proces op sommige aspecten geen uitkomst biedt, maak dan een gevoelsmatige keuze, maar pas aan als dit gewenst is.

0 antwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.