Product Backlog Management in Azure DevOps deel III
Azure DevOps is een samenwerkingstool voor verschillende teams. De bekendste functionaliteiten zijn de Scrumboards, zoals de Backlog en de Sprint Backlog en de wat meer technische functionaliteiten, zoals Pipelines en Pull Requests.
Het belang van Azure DevOps voor een Product Owner of Product Manager wordt vaak over het hoofd gezien. Hierdoor moeten deze mensen zich soms in bochten wringen om te zorgen dat de juiste informatie bij hun teams terecht komt.
Enige tijd terug heb ik een webinar gehouden over Product Backlog Management in Azure DevOps. Hierin ben ik dieper ingegaan op hoe Azure DevOps de Product Owner en Product Manager kan ondersteunen bij hun werkzaamheden.
In dit webinar heb ik tips gegeven over verschillende onderdelen van de processen die de Product Owner en Product Manager dagelijks uitvoeren. Ook gaf ik tips hoe je dat met ondersteuning van Azure DevOps kunt verbeteren of makkelijker kunt maken. Dit is deel III van een drieluik van blogs over Product Backlog Management en is een afgeleide van het webinar.
Effectief opstellen van de Product Backlog
Voor het opstellen van een Product Backlog heb ik een aantal suggesties:
Plan niet te ver vooruit. Als je een analyse of ontwerp doet voor veel Product Backlog Items, dan kom je er achter dat de ideeën die ooit beschreven zijn niet meer werkbaar zijn tegen de tijd dat ze gebouwd moeten worden. Dit kan te maken hebben met software die al gebouwd is, maar ook met veranderde wensen van gebruikers.
Zorg dat je gesprekken over de inhoud zoveel mogelijk doet met de betrokkenen. Dit geldt zowel voor alle teamleden als de stakeholders en eventuele gebruikers van de functionaliteit. Dit levert de meest correcte informatie en communicatie op om te zorgen dat de meeste waarde opgeleverd kan worden.
Een goed gerefined Product Backlog Item is klein genoeg om snel af te maken, maar groot genoeg om impact te hebben. Inspecteer dus regelmatig of een Product Backlog Item niet te groot is en wellicht opgesplitst kan worden.
Zoals in deel 1 van deze serie beschreven is, is het belangrijk om de organisatievisie en daarmee de productvisie mee te te nemen bij het prioriteren van de backlog. Als je dit doet, wordt het eenvoudiger om te bepalen welke items je uit gaat werken en beschikbaar gaat stellen aan je gebruikers.
Effectief opstellen van de Product Backlog in Azure DevOps
Gebruik in het Backlog scherm de volgorde zonder filters. Ik zie regelmatig dat Product Owners een filter zetten op de Backlog om makkelijker bij een set Product Backlog Items te kunnen. Alleen zonder filters is de volgorde van de Product Backlog compleet duidelijk.
Gebruik de hiërarchie in Azure DevOps. De standaard hiërarchie is Epic – Feature – Product backlog item. Door items te koppelen aan “hoger” gelegen items kun je makkelijk groeperen. Het gebeurt wel eens, dat Product Owners hier “tags” voor gebruiken. Het is verstandig om dat niet te doen en de hiërarchie te gebruiken, zoals deze bedoeld is. Tags kun je gebruiken om indicaties mee te geven.
Het is een klein beetje oneigenlijk gebruik, maar door gebruik te maken van “nep” Product Backlog Items kun je een soort van verdeler in je Backlog zetten.
Op deze manier kun je op een relatief makkelijke manier zien welke Product Backlog Item in je volgende release zit.
In Azure DevOps zitten al een aantal mogelijkheden om Product Backlog management makkelijker te maken. Een korte samenvatting daarvan:
- Gebruik filters, maar als je klaar bent, haal dan de filters van de Product Backlog af.
- Gebruik tags voor categorieën, maar niet voor hiërarchie.
- Gebruik het Business Value-veld om waarde indicatie te geven en houdt de discussie open over wat de waarde is van het op te leveren work item
Maak je werk makkelijker met plug-ins
Benut de mogelijkheden van plug-ins uit de Visual Studio Marketplace.
Er zijn veel extensies gemaakt voor Azure DevOps. Deze maken je werk makkelijker door aanvullende functionaliteit te bieden. Hier heb ik een aantal extensies geselecteerd waarvan ik heb gemerkt dat ze meerwaarde bieden.
De Sprint Goal extensie geeft het team de mogelijkheid om de sprintgoal te definiëren en bovenaan de Sprint Backlog weer te geven. Hierdoor wordt de focus voor de sprint vergroot, omdat men telkens herinnerd wordt aan het hoofddoel van de huidige sprint.
Personas geeft de Product Owner een simpele manier om een compleet beeld van de gebruiker te geven, waardoor deze meer gaat leven en het duidelijker wordt voor het team waarom dit Product Backlog Item gedaan moet worden[FV1] [AR2] . Door de context en de gebruiker duidelijker te definiëren wordt het voor de ontwikkelaar makkelijker om te begrijpen wat gewenst wordt.
Deze twee extensies zorgen dat het team een standaard set aan taken kan aanmaken voor een Product Backlog Item. Vaak begint een definition of done uit een aantal taken, die gedaan moeten worden. Omdat die standaard voor elke Product Backlog Item gedaan moeten worden kun je ze via deze extensies makkelijk aanmaken.
Specmap is een extensie die een digitale versie van een User Story Mapping maakt. Door deze te gebruiken krijg je een duidelijk overzicht wanneer bepaalde User Stories gedaan moeten worden en door de sleepmogelijkheid voor de Product Backlog Items in de mapping kun je makkelijk plannen.
Dit was het laatste deel van dit drieluik over Product Backlog management in Azure DevOps.
Zoals ook in deel 2 gezegd: het is people over processes over tools, dus de tools moeten het ons makkelijker maken, ze moeten niet onze manier van werken dicteren.
Heb je vragen of tips? Dan hoor ik ze graag.
Alex Roos, DevOps consultant
