agile Product roadmap

Waarom is een Product Roadmap belangrijk in een Agile omgeving?

In een agile omgeving vormt de roadmap een cruciale rol om context te geven aan het dagelijkse werk van een development team. Het helpt om tot een gedeelde waarheid te komen over de toekomst van een product. Maar hoe kom je tot een goede product roadmap? En hoe zorg je ervoor dat je het grotere plaatje kunt laten zien? We vertellen je er alles over in dit blog.

Voorkom de waan van de dag

De product roadmap is een visualisatie van de visie, richting en voortgang van een product, uitgezet in de tijd. Te vaak wordt er geprioriteerd in de waan van de dag. Hierdoor lijkt het laatste idee ook het belangrijkste. Het gevolg is dat er aan van alles tegelijk wordt gewerkt.

Wat mij betreft is de grootste mythe rondom agile dat er geen plannen worden gemaakt. Het gaat er juist om dat je in staat bent je plan aan te passen aan het snel veranderende landschap waarin we tegenwoordig actief zijn. Een inmiddels bijna 20 jaar oude waarde uit het Agile Manifesto vertelt ons nog steeds dat het gaat om

“Inspelen op verandering boven het volgen van een plan”

 

Een product roadmap is dus niet in beton gegoten maar moet juist helpen om in te spelen op veranderende klantfeedback en veranderingen in de markt. Dit doe je door nieuwe inzichten af te wegen tegen items op de roadmap. Moeten we meebewegen of vasthouden aan ons plan? Het is dus vooral een communicatiemiddel.

Hoe zet je de product roadmap in

Product owners gebruiken de product roadmap om de samenwerking met het development team te stimuleren en het helpt hen om consensus te bereiken over hoe het product zich zal ontwikkelingen in de tijd. Het versterkt daarmee de verbinding tussen teams en stakeholders. Teams hebben soms geen idee waarom ze aan bepaalde user stories werken. Met een goede product roadmap laat je het grotere plaatje zien.

Hoe kom je tot een product roadmap?

Een goede product roadmap valt of staat met een glasheldere product visie. Als je niet weet waar je heen gaat is elke route goed. Zorg dus eerst voor een gedeelde productvisie met het team en stakeholders. Als deze helder is kun je gaan bouwen aan de roadmap.

We beginnen met het bouwen van een roadmap door te kijken naar de bestaande features en ideeën op de backlog. Dat is ons vertrekpunt. Vaak is er een overdaad aan backlog items. Stel daarom voor iedere feature de volgende vragen:

  • Wat is de relatieve prioriteit?
  • Wanneer kan eraan gewerkt worden?
  • Hoeveel sprints zijn ervoor nodig?
  • Wat is de verdeling tussen design en ontwikkeling?

Door deze vragen te beantwoorden tijdens een product roadmap workshop kun je al binnen twee uur een strakke roadmap hebben staan.

Hoe organiseer je een product roadmap workshop?

Wanneer wij als Tribers aan de slag gaan met het bouwen van een roadmap plannen we een sessie in met een aantal stakeholders en het development team. Door het samen te doen ontstaat er meer begrip tussen de keuzes die gemaakt worden. Dan blijkt de zogenaamde kloof tussen business en IT eigenlijk wel mee te vallen en verschillen de ambities en belangen niet veel van elkaar.

Tijdens de workshop zijn we vooral op zoek naar de features waarvan we verwachten dat die het meest bijdragen aan de product visie. Dit doen we in twee rondes.

Ronde 1: prioriteren op basis van relatieve waarde.

We gaan eerste bepalen in hoeverre de features, ten op zichtte van elkaar, bijdragen aan het bereiken van de visie. Dit doen we in 3 stappen:

  1. Pitch in een minuut waarom de feature belangrijk is
  2. Geef het team de ruimte om een minuut lang verhelderende vragen te stellen
  3. Kies met elkaar een plek op de (virtuele) muur gebaseerd op relatieve waarde.

De eerste feature gebruik je als referentie en vanuit daar kies je steeds of de volgende feature belangrijker of minder belangrijk is dan de features op de muur. Herhaal dit tot je alle features relatief hebt geprioriteerd. Als je een tool als Miro gebruikt ziet dat er uiteindelijk zo uit:

Relatieve Prioritering
Relatieve Prioritering

Ronde 2: inschatten en plannen

In de tweede ronde gaan we bepalen wanneer er aan een feature gewerkt kan worden en hoeveel sprints het team nodig denkt te hebben. Dit wordt dus de daadwerkelijke roadmap. Hierin nemen we de volledige verwachtte doorlooptijd mee. Dus niet alleen het development gedeelte maar ook onderzoek, design en analyse.

  1. Vraag het team om een inschatting van het aantal sprints
  2. Faciliteer een discussie van 2 minuten om verschillende perspectieven te delen
  3. Plaats de feature op de roadmap op basis van het aantal verwachtte sprints
  4. Maak een onderscheid tussen voorbereiding en bouwen zodat je inzicht hebt wanneer de nadruk op refinement ligt en wanneer op bouwen.

Zo heb je aan het eind van de sessie je eerste product roadmap gemaakt die er ongeveer zo uit ziet:

Product roadmap

Het belang van een product roadmap

Voor management helpt de roadmap om te begrijpen waar het team staat en waar het de komende tijd aan gaat werken. Beperk daarom technische termen en kies woorden die voor iedereen begrijbbaar zijn. Probeer te voorkomen dat wanneer je de roadmap toont mensen opnieuw vragen wat er ook alweer bedoeld wordt met bepaalde items. Focus op wat het oplevert voor de klant en maak het begrijpbaar. Een goede product roadmap helpt je om in te spelen op veranderende klantbehoefte door nieuwe features af te wegen tegen bestaande roadmap items.

Lees meer

Whitepaper Digitale Transformatie

Digitale transformatie en Organisatiecultuur

Zeven pijlers van een digitale cultuur die bijdragen aan een succesvolle digitale transformatie

 

 

Lees meer
Agile Dean Leffingwell

5 lessen van SAFe bedenker Dean Leffingwell in Denver

Dean geeft antwoord op verschillende uitdagingen.

Lees meer
Maturity modellen

Weten waar je teams staan in hun Agile ontwikkeling?

De Do’s en don’ts van Agile maturity modellen

Lees meer
Agile Team

HR in Agile teams

4 inzichten om als scrum master het verschil te maken.

Lees meer
All posts