Product Backlog Management in Azure DevOps deel I
Azure DevOps is een samenwerkingstool voor teams. De meest bekende functionaliteiten zijn de Scrumboards, zoals de Backlog en de Sprint Backlog, en de wat meer technische functionaliteiten, zoals Pipelines en Pull Requests. Het nut voor de Product Owner of Product Manager wordt vaak over het hoofd gezien, waardoor deze mensen zich soms in bochten moeten wringen om te zorgen dat de juiste informatie bij hun teams terecht komt.
Laatst heb ik een webinar gehouden over hoe Azure DevOps de Product Owner en Product Manager kan ondersteunen in hun werkzaamheden. Daarin gaf ik tips over verschillende onderdelen van de processen die de Product Owner en Product Manager dagelijks uitvoeren. Ook gaf ik tips hoe je dat met dat met ondersteuning van Azure DevOps kunt verbeteren of makkelijker kunt maken. Dit is deel I van een drieluik van blogs over Product Backlog Management en is een afgeleide van het webinar.
Het bepalen van waarde van wensen uit de organisatie
Organisatie en product visie
Er zijn verschillende methoden die gebruikt worden om de waarde te bepalen. Eén die redelijk logisch is, maar vaak vergeten wordt, is de “hiërarchie”. Hiermee bedoel ik hoe je komt van de visie van de organisatie naar de productvisie en naar de productgoal. Door deze goed voor ogen te houden, kun je de visie van de organisatie en de productvisie (en daarmee de product goal) laten terugkomen in je Product Backlog. De Product Backlog Items die aan deze visies gelinkt zijn, zouden logischerwijs hoger op de Backlog moeten komen dan vergelijkbare Product Backlog Items die niet aan de visie gelinkt zijn.
Workshops
Door het gebruik van workshops met stakeholders en gebruikers kun je daarnaast een beter beeld krijgen wat de klant of gebruiker wil. Deze contactmomenten met mensen buiten het team zijn dus waardevol, niet alleen voor de Product Owner, maar ook voor de teamleden. Hoe meer informatie je hebt, hoe makkelijker het is om beter te bepalen welk Product Backlog Item meer waarde oplevert aan het product.
Meetbaar bepalen van waarde
Ten slotte kun je door gebruik van de schaal van Fibonacci een indicatie geven wat meer waard is en wat minder. Voor Product Backlog Items kunnen verschillende indicatoren zijn waarom iets veel waarde heeft. Denk hierbij aan:
- Als we het niet maken, overtreden we dan de wet?
- Als we dit maken, trekken we meer klanten aan?
- Als we dit maken, gaan klanten meer kopen of betalen?
- Kunnen we hiermee een kostenvoordeel halen?
Hoe je dit zou kunnen opzetten wordt beschreven in onderstaande blogs:
Business Value additional criteria
Al deze vragen worden op een andere manier geïnterpreteerd. Door dit soort vragen dezelfde schaal te geven, kun je de waarden gelijktrekken en daarmee een rekenkundige vergelijking maken welke Product Backlog Item (PBI) de meeste waarde levert.
Het bepalen van waarde in Azure Devops
In de Product Backlog Item is een ‘veld’ Business Value. Deze kan gebruikt worden om een numerieke waarde op te slaan. Daarnaast kun je natuurlijk gebruik maken van de velden die standaard in de Product Backlog Items staan. Dit zijn allemaal tekstvelden en daar zit geen logica achter om je echt te kunnen helpen.
Plannen en forecasten
Het plannen van een Scrum project is vaak een lastig punt. Er zijn veel variabelen die zorgen dat een plan of planning niet zo uitkomt als van tevoren bedacht. Dat zit ook in de natuur van software ontwikkelprojecten. Toch zijn er wel mogelijkheden om de planning iets scherper te krijgen dan gebruikelijk is.
Hoe kleiner de opleveringen zijn (releases), hoe minder relevant een volledige planning wordt. Als je namelijk elke dag meerdere keren functionaliteit aan je gebruikers kunt geven, is de feedback die je van je gebruikers krijgt, ook weer sneller bij jou. En dat zorgt ervoor dat je plan kort-cyclisch bijgesteld kan worden. Daarnaast kunnen gebruikers eerder werken met software, waardoor zij de totaalplanning minder interessant vinden.
Er kan een reden zijn waarom je voor bepaalde Product Backlog Items een harde datum wil afgeven. Een voorbeeld is wijzigingen in wet- en regelgeving die op een bepaalde datum ingaat. Probeer dit echter tot een minimum te beperken en verder zo min mogelijk vaste opleverdatums af te geven. Het gaat erom dat we waarde leveren. Als een opleverdatum gezegd wordt, al is het een indicatieve datum, wordt deze datum het focuspunt van de werkzaamheden in plaats van de waarde die geleverd wordt.
Plannen en forecasten in Azure DevOps
In Azure DevOps is een planbord, waarin je een duidelijk overzicht kan creëren voor een planning.
Belangrijk in het plannen, is dat je niet alles achter elkaar of tegelijk moet plannen. Dit levert namelijk alleen maar vertraging op in het leveren van waarde
Dit zijn alvast drie aandachtspunten om het werk van jou als Product Owner makkelijker en overzichtelijker te maken in Azure DevOps. Houd wel de DevOps gedachte in de gaten: People over Processes over Tools. Met andere woorden: Azure DevOps is een hulpmiddel om de processen te begeleiden om daarmee het voor mensen prettiger en makkelijker te maken.
Binnenkort deel II van de serie blogs over Product Backlog Management in Azure DevOps.
Heb je vragen of tips? Dan hoor ik ze graag.
Alex Roos, DevOps consultant
