Introductie van de productbacklog

Als het eenmaal duidelijk is wat voor resultaten je wilt behalen, kan het team samenkomen en tactisch aan de slag gaan met de productideeën die helpen met het behalen van deze resultaten. De eerste pragmatische stap die je kunt nemen om dat te bereiken is het implementeren van een productbacklog.

Tijdens ons werk komen we veel productteams tegen die één Jira-backlog gebruiken om alles vast te leggen: functieverzoeken, kleine en grote kansen, taken en subtaken, bugs en urgente issues, evenals ideeën over de volgende stappen van een product.

Ze vertellen ons steevast hetzelfde verhaal. De backlog neemt ongecontroleerd in omvang toe door de lijst van tickets die steeds langer wordt, wat bij teams tot stress leidt. Deze ongeorganiseerde, overweldigend grote backlogs ondersteunen op geen enkel niveau de prioritering, van tactische veranderingen tot grote nieuwe investeringen.

De teams hebben deze discussies uiteindelijk in spreadsheets verwerkt, maar het was elk kwartaal hetzelfde liedje. Inzichten gingen verloren, beslissingen werden niet geregistreerd en resources werden toegewezen onder tijdsdruk, op basis van onderbuikgevoel en sterke meningen.

Er bestaat een betere manier: een speciale productbacklog die is gebaseerd op resultaten, die anders is dan de leveringsbacklog voor de dagelijkse werkzaamheden.

Wat is een productbacklog?

In de productbacklog worden ideeën gecreëerd, geprioriteerd en gedeeld in de vorm van roadmaps, gekoppeld aan resultaten en doelen. De productbacklog bevat alle productideeën, inzichten, kansen en oplossingen en wordt beheerd door het productteam. Hier worden geen specifieke taken gepland die moeten worden uitgevoerd. In plaats daarvan worden er zaken besproken als 'waar moeten we in investeren en waarom?'. Belanghebbenden in het hele bedrijf kunnen worden uitgenodigd voor deze backlog, om samen te werken aan prioriteiten en roadmaps en om de voortgang van productinitiatieven in uitvoering op hoog niveau te bespreken.

Beschouw de productbacklog als een hub voor het productteam, die kan worden gedeeld met teamgenoten uit het hele bedrijf. De productbacklog is een speciale ruimte voor alles wat een team wilt bijhouden, van vage ideeën tot volledig uitgewerkte mogelijkheden. Deze kunnen ze in de loop van de tijd verfijnen op basis van leerervaringen, feedback van klanten en veranderende algemene doelen.

Productbacklog versus leveringsbacklog

De productbacklog verschilt van de leveringsbacklog, aangezien ze allebei een andere functie hebben. 

De leveringsbacklog is bedoeld voor het beheren van leveringswerk, het opstellen van leveringsplannen en het volgen van de voortgang. Deze backlog bevat de werkverdeling (epics, story's, taken en subtaken) voor het leveren van werkzaamheden en wordt beheerd door het technische team. In deze backlog komt het hele team samen om problemen met de levering te bespreken: volgorde, afhankelijkheden, capaciteit, technische mijlpalen.

Het is duidelijk dat de productbacklog en leveringsbacklog nauw met elkaar verbonden zijn. Werkzaamheden in de leveringsbacklog zijn verbonden met ideeën in de productbacklog, die op hun beurt verband houden met de gewenste resultaten. Dit geeft leiders, managers en ontwikkelaars een overzicht van hoe het team werkt om resultaten te realiseren terwijl ze door cycli van ontdekking en levering bewegen.

In tegenstelling tot bij de productbacklog zijn alle items in de leveringsbacklog bedoeld als concrete plannen, die uiteindelijk moeten worden voltooid. De productbacklog is daarentegen bedoeld voor het bedenken van en brainstormen over ideeën, evenals voor planning. Sommige productideeën krijgen nooit prioriteit en worden nooit toegevoegd aan roadmaps, en dat is oké.  

Door het grote geheel van productproblemen te scheiden van de leveringsplanning en -tracking, kunnen teams effectiever prioriteiten stellen, werk koppelen aan resultaten, evenals onoverzichtelijke backlogs vermijden.

Voordelen van een productbacklog

Het gebruik van aparte productbacklogs en leveringsbacklogs biedt veel voordelen:

• Een backlog is een veilige plek voor het productteam om potentiële ideeën en beschikbare gegevens te bespreken, zonder dat ze hoeven na te denken over hoe haalbaar of gedefinieerd deze ideeën zijn. 

• Backlogs maken discussies op één plek mogelijk, zodat teams in de loop van de tijd kennis kunnen vergaren zonder dat ze in tientallen spreadsheets hoeven te zoeken.

• Een backlog creëert een gedeelde bron van waarheid en zorgt voor een gedeeld begrip van productprioriteiten. Hierdoor wordt een veelvoorkomend probleem vermeden waarmee productteams worden geconfronteerd: besluitvorming op basis van onderbuikgevoel of sterke meningen van klanten en belanghebbenden. 

• Een backlog zorgt voor transparantie bij de discussies over prioritering, waardoor iedereen uit het hele bedrijf naar een gedeelde ruimte wordt gebracht. Dit neemt veel spanning weg bij de samenwerking tussen belanghebbenden en klantgerichte teams.

• Een backlog is gekoppeld aan leveringswerk, waardoor roadmaps altijd actueel en eerlijk blijven, omdat er rekening wordt gehouden met leveringsbeperkingen.

De productbacklog organiseren

Ideeën, mogelijkheden, problemen, oplossingen: het productteam moet beslissen wat er in de productbacklog wordt opgenomen. Dit moeten zaken zijn die het team wilt prioriteren, evenals hoe het team denkt over productinvesteringen en -prioriteiten.

Het is erg belangrijk voor het productteam om te bepalen wat er in de productbacklog terechtkomt en welke structuur wordt gebruikt om ideeën te categoriseren en te prioriteren. Anders lopen ze het risico dat de backlog chaotisch wordt en dit is juist wat ze proberen te vermijden.

Om de backlog onder controle te houden, moeten externe belanghebbenden worden uitgenodigd met vooraf gedefinieerde manieren om alleen bij te dragen, in plaats van directe bevoegdheden te krijgen voor het aanmaken en bewerken van items. Deze bijdragers kunnen bijvoorbeeld opmerkingen toevoegen, op ideeën stemmen of de klant taggen die om een functie heeft gevraagd.

Hieronder staan twee aanbevolen structuren voor productbacklogs: boulders (rotsblokken), rocks (keien) en pebbles (kiezelstenen), en lange, middellange en korte lijsten. We raden aan om de productbacklogs rond deze drie buckets en deze activiteiten te organiseren.

In Jira Product Discovery doe je dit door specifieke weergaven te configureren om de juiste ideeën weer te geven, en te kiezen welke velden je wilt tonen om de discussie te ondersteunen (selecteren, beoordelen) en om samenwerking te bevorderen (inzichten, stemmen, opmerkingen, reacties).

Rotsblokken, keien en kiezelstenen

Veel productteams hebben maar één objecttype: 'idee'. Maar de backlog kan items bevatten met verschillende vormen, grootten en detailniveaus, van belangrijke nieuwe keuzes tot kleine productverbeteringen. 

Het is gebruikelijk om een backlog te structureren met drie categorieën items: 

• Boulders (rotsblokken): grote investeringen, strategische kansen en belangrijke nieuwe keuzes

• Rocks (keien): middelgrote investeringen, aanzienlijke productverbeteringen die leiden tot resultaten

• Pebbles (kiezelstenen): kleine investeringen, zoals het oplossen van kleine bugs en issues met betrekking tot de gebruikerservaring

Het is het beste om hier aparte ruimtes voor te creëren in de productbacklog. Ook is het belangrijk dat de investeringen gelijkmatig zijn verdeeld onder de drie categorieën, waarbij voor elke investering budget en ruimte op de roadmap wordt gereserveerd. Vooral kiezelstenen zijn moeilijk te prioriteren zonder dit soort intentionaliteit. Een belangrijke nieuwe keuze is spannend, maar kleine problemen hebben een algeheel negatief effect op de gebruikerservaring. 

Meer informatie over deze structuur vind je in de sectie Ideeën.

Lange lijst, middellange lijst en korte lijst

Een andere eenvoudige, pragmatische manier om een productbacklog te structureren, komt van Brent Johnston. Hij was een van de eersten die begon met het gebruik van Jira Product Discovery. Brent omschreef productwerk als voortdurend werken met drie buckets: de lange lijst, de middellange lijst en de korte lijst.

Het productteam verwerkt ideeën van de lange, middellange en korte lijst in de productbacklog en nodigt belanghebbenden uit het hele bedrijf uit om samen te werken.

• De lange lijst bevat alles: ideeën van de categorie 'misschien ooit', problemen, mogelijkheden en oplossingen. Er zouden meer dan 200 ideeën op deze lijst kunnen staan. 

  • Het productteam stelt deze lange lijst samen en gebruikt zijn kennis van de markt, strategische en operationele kwesties en de behoeften van klanten en bedrijven om er een middellange lijst van te maken.

• De middellange lijst is een voorselectie van mogelijke priority's: aantrekkelijke kansen waarin het team echt zou kunnen investeren. Van de lange lijst met 200 ideeën, kunnen er 10 tot 20 op de middellange lijst komen.

  • Dit zijn de ideeën die goed lijken omdat ze strategisch belangrijk zijn, vaak naar voren komen in discussies met klanten of omdat er een goede kans bestaat dat ze gebruikers tevreden te stellen. Ze moeten worden geprioriteerd in een korte lijst, meestal op basis van input van verschillende belanghebbenden in het bedrijf. 

    • Zie Prioritering voor meer informatie.

• De korte lijst is in feite de productroadmap: ideeën die het productteam verder wilt onderzoeken. Deze taken zorgen ervoor dat mogelijkheden, problemen en oplossingen worden uitgevoerd. Hierdoor kan een productervaring worden gecreëerd of een bestaande productervaring worden verbeterd. 

  • Het team controleert deze lijst regelmatig op basis van wat het leert, en houdt de lijst up-to-date. Dit is de lijst waarvan de rest van het bedrijf het vaakst een update kan verwachten.

    • Raadpleeg Roadmaps voor meer informatie.

Hoe maak je een productbacklog in Jira Product Discovery?

We hebben Jira Product Discovery gemaakt als een plek waar productteams hun ideeën kunnen samenbrengen, eraan kunnen samenwerken en prioriteiten kunnen stellen. Binnen Jira Product Discovery kun je een of meer productbacklogs aanmaken, genaamd 'Discovery Projects'. 

Over het algemeen is het het beste om mensen die dagelijks samenwerken in hetzelfde project te plaatsen (bijvoorbeeld een team of meerdere teams). Maar een aantal klanten van Jira Product Discovery gebruiken één project om meerdere teams en producten te hosten. Dit is vooral handig als er een hoge mate van samenwerking vereist is tussen deze teams.

Hier is een demo over hoe je dat moet doen:

Met het Jira Product Discovery Premium-abonnement kun je ideeën van meerdere projecten op één plek visualiseren door weergaven te maken waarin ideeën uit meerdere projecten worden weergegeven en het hele verhaal van de productplannen van een organisatie wordt verteld.

Wat is er nog meer?

In de rest van dit handboek leggen we in detail uit hoe je een productbacklog kunt gebruiken om:

• Ideeën van begin tot uitvoering

• feedbackkanalen opzet en inzichten verzamelt om ideeën te valideren

• prioriteit geeft aan de ideeën die impact hebben

• roadmaps te maken waar je teams en belanghebbenden achter staan

We geven voorbeelden van hoe we dit doen in het Jira Product Discovery-team, met behulp van Jira Product Discovery en andere producten.