3 voorbeelden van productbacklogs die goed zijn uitgevoerd (+ wat je niet moet doen)
Heb je ooit naar je backlog gekeken en gewild dat je alles erop kon verwijderen om helemaal opnieuw te beginnen? Nou, ik heb dat gevoel meer dan eens gehad, want productbacklogs opbouwen en onderhouden is geen eenvoudige opgave. Maar om je te laten zien hoe je backlogs goed aanpakt en je te inspireren om je eigen backlog op te schonen, deel ik graag vier uitzonderlijke voorbeelden van productbacklogs met je.
Waar gaat de productbacklog in Agile en Scrum over?
De productbacklog is een levend document met alle items waaraan het productteam, de scrummaster en het engineeringteam van plan zijn te werken om hun product te bouwen.
De backlog omvat alles wat je nodig hebt om je product te bouwen en te onderhouden, waaronder nieuwe functies, taken voor technische schuld, verbeteringen van technische processen uit je meest recente retrospectieve, QA-automatiseringstaken en meer.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Het belangrijkste kenmerk van een productbacklog is dat het een geprioriteerde lijst is, waarbij items bovenaan de hoogste prioriteit hebben en het team deze als eerste moet oppakken wanneer het de sprints plant (of wanneer er ruimte over is op het kanbanbord).
Productbacklog versus sprintbacklog versus productroadmap: wat is het verschil?
Bij Agile-projectmanagement en in het bijzonder de scrummethodologie is een productbacklog niet de enige lijst met items die de producteigenaar voor je ontwikkelingsteam opstelt. Er zijn ook de sprintbacklog en de productroadmap. Maar wat is het verschil? Laten we dat bekijken.
Sprintbacklog: dit is een subset van de grotere backlog en bevat alleen de items die het scrumteam tijdens een sprintplanningsbijeenkomst heeft opgenomen in de volgende sprint of een ander type iteratie. De items hierin zijn meestal goed uitgewerkt en bevatten story points.
Productroadmap: dit is een document op hoofdlijnen dat de belangrijkste functies en mijlpalen voor het product toont. In tegenstelling tot de backlog, die meer tactisch van aard is en beschrijvingen van functies bevat, is de productroadmap strategisch. Het doel ervan is om teamleden en belanghebbenden te laten zien welke richting het product opgaat en wat de belangrijkste aandachtsgebieden zijn.
Nu jij en de belangrijkste concepten goed zijn geïntroduceerd, ga ik meteen uitleggen hoe je je productbacklog beheert (en hoe je dat, eh, niet moet doen).
Hoe je het NIET goed doet: een verschrikkelijk voorbeeld van een productbacklog
Het begrijpen van antipatronen bij het opstellen en beheren van productbacklogs is waarschijnlijk net zo belangrijk als het leren van best practices. De reden is dat je, als je niet weet dat iets een antipatroon is, het risico loopt dat je het in je backlog opneemt en denkt dat dit normaal en alledaags is.
Laten we het onderstaande voorbeeld bekijken om enkele werkwijzen te bespreken die de kwaliteit van je backlog aanzienlijk kunnen verminderen.
Terug naar het voorbeeld. Neem de tijd om het aandachtig te bekijken.
Het ziet er verschrikkelijk uit, vind je niet? Als we naar deze backlog kijken, zullen de meesten van ons in feite twee emoties ervaren:
- Afkeer van de rommelige items in deze backlog.
- Schuldgevoel, want laten we eerlijk zijn: we hebben allemaal wel eens een backlog gehad die er zo uitzag (ik ook natuurlijk).
Laten we de problemen in deze backlog nu uitsplitsen.
Overvloed aan items in de productbacklog
Is het je opgevallen dat er 665 issues in deze backlog stonden? De grootste backlog die ik met “plezier” heb beheerd, bevatte meer dan 2.500 items.
Het probleem met een overvolle backlog is dat je bijna zeker niet meer weet wat elk item inhoudt en waarom je het op een bepaalde positie of met een bepaalde prioriteit in je backlog hebt geplaatst. Omdat je geen idee hebt waar deze taken over gaan, is de kans klein dat je ze naar je volgende verfijningssessie meeneemt, de details ervan bespreekt en ze in de komende sprint opneemt.
Zo eindig je met een enorme, onbeheerbare puinhoop die zich oneindig blijft opstapelen.
Onjuiste prioritering van de backlog
Een ander probleem dat je misschien op deze backloglijst hebt opgemerkt, is dat er werkitems met de prioriteiten “Laagste” en “Laag” bovenaan staan — boven items met de prioriteit “Hoogste”.
Dit is een typisch geval waarin je backlog niet goed is geprioriteerd. Daar kunnen veel redenen voor zijn, maar de meest waarschijnlijke is dat je een item met een “Hoge” prioriteit lager op de backlog hebt geplaatst, maar bent vergeten het prioriteitsveld aan te passen.
Gebrek aan detail
Is het je opgevallen dat er een item staat met de tekst “Ik wil naadloze integratie met alle socialemediaplatforms”? LOL. Dat is niet eens een goed gebruikersverhaal, gezien de enorme reikwijdte die het bestrijkt. De reikwijdte is zo groot dat je in de praktijk meerdere epics zou moeten hebben, waarbij elke epic de verhalen voor één socialemediaplatform bevat.
Naast de enorme reikwijdte is het probleem met dit item (en eigenlijk met elk item in deze backlog) de vaagheid ervan. Gebruikersverhalen horen een specifieke gebruikerservaring en handeling te beschrijven.
Stel je voor dat je dit verhaal meeneemt naar de backlogverfijningssessie met je Agile-team. Je zou een stortvloed aan vragen krijgen over vrijwel elk aspect van het verhaal.
“Wat bedoel je met naadloos?” “Hoe ziet de integratie eruit?” “Met welke socialemediaplatforms integreren we?!”
“Ik wil alles, en wel nu”
Een andere rode vlag die je misschien op de backlog hebt opgemerkt, was dat 70% van de items daarop de prioriteit “Hoogste” had. Dit is een andere typische situatie wanneer je bij het instellen van prioriteiten puur vertrouwt op de meningen van je belanghebbenden (en elke belanghebbende zijn items belangrijk vindt), zonder te proberen ze objectief te beoordelen en hun belang te vergelijken met dat van andere items op de lijst.
Nu we hebben gedefinieerd hoe een slechte backlog eruitziet, gaan we deze verbeteren en vier goede voorbeelden van backlogs bespreken... zodat jij je backlog weer geweldig kunt maken.
3 voorbeelden van goed ingerichte backlogs
Voordat ik je deze voorbeelden laat zien, wil ik opmerken dat er niet één juiste manier is om een geweldige backlog te maken. Hoe je backlog eruitziet, hangt af van de aard van je product, de volwassenheid ervan, de omvang van je bedrijf/team enzovoort.
In werkelijkheid is een geweldige backlog een backlog die bij iedereen duidelijkheid en overeenstemming kan creëren over de huidige en komende reikwijdte van je product.
Er zijn echter algemene manieren waarop je je backlog kunt beheren, waardoor deze voor iedereen overzichtelijker en eenvoudiger te gebruiken wordt. Elk van de onderstaande voorbeelden vertegenwoordigt zo’n best practice.
Voorbeeld #1: Een backlog met secties
Het is bijna nooit goed om een backlog met honderden of duizenden items te hebben. Een honderdtal items is echter meestal heel gebruikelijk en normaal. Maar zelfs met honderd items op je backlog is het gemakkelijk om te vergeten waar elk item over gaat of ze lange tijd onaangeroerd te laten zonder ze aan je komende sprints toe te voegen.
Om je backlog overzichtelijker te maken, kun je overwegen deze op te delen in secties.
Sommige productmanagers gebruiken secties graag om items te groeperen op basis van hun aandachtsgebieden of mijlpalen. Zelf gebruik ik hiervoor liever tags voor Versie, Epic en Component bij taken en deel ik mijn backlog op in secties op basis van de reikwijdte van komende sprints.
Dit is een geweldige manier om voor het overgrote merendeel van de items op je backlog een sprint (of op zijn minst een globale implementatietijdlijn) toe te wijzen en ervoor te zorgen dat geen enkele taak wordt verwaarloosd.
Een andere gebruikelijke manier om een backlog met secties te beheren, is door items te groeperen op basis van hun verfijningsstatus/werkstroom (iets waarbij AI in backlogbeheer kan helpen). In dit geval stroomlijn je je proces met de volgende secties:
- Huidige sprint
- Gereed voor planning
- Gereed voor verfijning
- Backlog
Wat je in dit geval doet, is productvereisten en beschrijvingen toevoegen aan de items in de backlog. Wanneer de vereisten gereed zijn, stuur je ze naar de sectie “Gereed voor verfijning”, die als scope voor je volgende verfijningsbijeenkomst dient.
Na het verfijnen van een item verplaats je het naar de sectie “Gereed voor planning”, waarmee je aangeeft dat het gereed is en het team het kan opnemen in de komende sprint.
Voorbeeld #2: Een backlog met goed geplaatste componenten, epics en versies
Door je backlog op te delen, wordt deze zeker overzichtelijker en beter georganiseerd. De beperking van het gebruik van alleen segmentatie is echter dat je je backlog slechts op basis van één criterium kunt organiseren (bijvoorbeeld de sprints, de verfijningsstatus enzovoort).
Gelukkig bieden moderne productbacklogtools je een breder scala aan opties om je takenlijst voor productontwikkeling te organiseren op basis van meerdere criteria. Kijk maar eens naar deze prachtige backlog.
Ziet deze er niet goed georganiseerd en aantrekkelijk uit? In dit specifieke geval hebben we gebruikgemaakt van de volgende functies om onze backlog beter beheersbaar te maken:
Componenten
Dit veld/kenmerk beschrijft traditioneel het gebied van het product waaraan je de betreffende functie wilt toevoegen. In het bovenstaande voorbeeld zijn de componenten de afzonderlijke producten waaruit Grammarly bestaat.
Een andere gebruikelijke manier om componenten te gebruiken, is door verhalen/taken te organiseren op basis van de technologie die nodig is om de functie te creëren. Voor webapplicaties kun je bijvoorbeeld front-end- en back-endcomponenten hebben om het werk en de afhankelijkheden te organiseren tussen engineers die gespecialiseerd zijn in client- of serverontwikkeling.
Versies/releases
Met dit kenmerk documenteer je alle functies en bugfixes die je scrumteam met een bepaalde versie van je product zal uitbrengen. Het bijhouden van versies in de backlog biedt twee zeer waardevolle voordelen.
- Het helpt je bij het plannen van je sprints en releases. Als je bijvoorbeeld over 2 weken een release plant, moet je er tijdens de planningsbijeenkomst voor zorgen dat je alle taken die voor die releaseversie bedoeld zijn, in de sprint opneemt.
- Je kunt alles documenteren wat je team in een bepaalde versie heeft gestopt en problemen eenvoudig terugvinden wanneer er iets in productie gebeurt.
Stel je bijvoorbeeld voor dat mensen Captcha-fouten beginnen te krijgen in je registratieproces in de nieuwste versie 1.3.2. Wanneer je zoekt naar de taak op basis waarvan je team wijzigingen in de captcha-configuraties heeft aangebracht, zie je dat deze bij versie 1.3.1 hoort. Dat betekent dat je moet teruggaan naar versie 1.3.0 of een hotfix moet uitvoeren.
Epics
Ik denk niet dat ik hoef uit te leggen wat een epic is en wat de voordelen zijn van het gebruik ervan. Maar als je dieper wilt ingaan op de best practices en de fijnere details van epics, kun je onze gids over epics (woordspeling bedoeld) bekijken.
Voorbeeld #3: Een backlog met de juiste hoeveelheid details voor elke sectie
Dit is een best practice die je waarschijnlijk in veel boeken en theoretische artikelen over Agile en productmanagement bent tegengekomen. Hoewel we naarmate we meer ervaring opdoen wat sceptischer worden tegenover theoretische concepten, is deze in de praktijk daadwerkelijk nuttig.
Het idee is dus dat de items bovenaan veel details moeten bevatten en dat je ze idealiter minstens één keer door een verfijning van de productbacklog hebt geleid. De items onderaan de backlog zouden daarentegen weinig details moeten bevatten, omdat de kans groot is dat je iets nieuws leert over je product en eindgebruikers en dat dit item daardoor verouderd raakt.
Dit betekent dat het item bovenaan je backlog er als volgt uitziet (of zelfs gedetailleerder):
Je verhalen onderaan je backlog zouden veel minder details moeten bevatten en er als volgt uit moeten zien:
En welke verhalen en initiatieven je ook in het midden van je backlog hebt staan, die zullen een gemiddeld detailniveau hebben.
Voorbeeld nr. 4: Ik weet dat het voor de hand ligt, maar... een schone backlog
Ik weet dat het niet eenvoudig is om je backlog schoon te houden. Ik heb het vaak genoeg meegemaakt en weet dat het als een vervelende klus voelt. Toch zijn het niet doornemen van alles in je backlog en het eraan denken om verouderde items te verwijderen belangrijke factoren die de kwaliteit van je backlog bepalen.
Het is niet altijd eenvoudig om dingen uit je backlog te verwijderen. Er zijn echt mooie functies die je ooit hoopt te bouwen (voornamelijk zaken die prettig zijn om te hebben) en soms wil je ze echt niet verwijderen. Maar op een bepaald moment moeten we eerlijk zijn: je weet dat je het nooit gaat implementeren. En zelfs als je dat wel doet, zou dat betekenen dat je geen functies met hoge prioriteit meer hebt, wat over het algemeen geen goed teken is.
Soms zijn het je belanghebbenden die deze verouderde items aan je backlog hebben toegevoegd. Voordat je ze verwijdert, probeer je te vragen of hun verzoek nog steeds van kracht is, en hun antwoord is bijna altijd ja. Welnu, als het verzoek meer dan 6 maanden oud is en ze het al waren vergeten, overtuig ze er dan gewoon van dat het niet dringend is (als dat wel zo was, zouden ze er meerdere keren achteraan zijn gegaan) en verwijder het.
Een geweldige backlog is wat voor jou het beste werkt
Als je al deze best practices hier in overweging hebt genomen, zou je dan een geweldige backlog hebben? Ze zullen zeker helpen, maar ze garanderen geen uitmuntendheid.
Vergeet niet dat het doel van de backlog is om voor iedereen een enige bron van waarheid te zijn. Naast deze best practices moet je dus rekening houden met de behoeften en werkwijze van je team en belanghebbenden, en je backlog zo opbouwen dat die hen helpt om op één lijn te blijven.
Deze handleiding over geweldige backlogs maakt deel uit van een grotere serie over alles wat met Agile te maken heeft. Abonneer je op onze nieuwsbrief voor meer handleidingen en inzichten zoals deze, die tweewekelijks in je inbox worden bezorgd!
