Expert in requirements

3 must haves waar je als agile analist niet omheen kunt

Gereedschapsriem en helm

Als analist in een agile-omgeving word je aangesproken op je vakmanschap. Dit geeft je veel vrijheid, maar ook veel verantwoordelijkheid. Vakmensen zijn immers professionals die zelf het beste weten hoe ze hun werk moeten uitvoeren. Agile kent daarom geen voorgeschreven of verplichte methoden en technieken. Alleen principes, regels en heel veel best practices.

Scrum is geen methode die voorschrijft welke werkzaamheden je moet uitvoeren, welke (tussen)producten je moet opleveren en welke technieken je daarbij kunt gebruiken. Scrum is een raamwerk. Het schept de kaders waarbinnen de teamleden naar eigen inzicht de in hun situatie best passende werkwijze kiezen. Dit zou je kunnen vergelijken met een voetbalwedstrijd. Een team en de spelers zijn vrij om naar eigen inzicht te handelen, zolang ze zich aan de spelregels houden. De ondertitel van de officiële Scrum Guide is niet voor niets ‘The Rules of the Game’.

Als jij of de mensen waarmee je samenwerkt nog niet zoveel ervaring met agile hebben, valt het niet altijd mee om de juiste werkwijze te kiezen. Om je een vliegende start te geven, volgen hier 3 must haves waar je als agile analist of product owner aan moet denken.

1. Gedeelde productvisie als vizier

Zorg dat er vanaf het begin een gedeelde productvisie is met daarin de te behalen bedrijfsdoelstelling en het gewenste eindresultaat. Anders weet je niet welke businesswaarde je moet leveren of beter gezegd: anders kun je er niet voor zorgen dat de ontwikkelde software veel toegevoegde waarde levert. Dat is immers je eerste prioriteit als agile analisten. Zeker wanneer de rest van het agile team deze focus onvoldoende heeft, is een goede agile analist onmisbaar.

Helaas zie ik maar al te vaak discussies over de businesswaarde ontstaan. Zonder productvisie heb je bijvoorbeeld niets om de businesswaarde en prioriteit van een user story aan te relateren. Het draait dan vaak uit op persoonlijke voorkeuren en meningen van stakeholders. Het is bijna onmogelijk om dan een doelgerichte koers te varen.

2. DEEP productbacklog als actielijst

D.E.E.P.

Vrijwel ieder project heeft tegenwoordig wel een product backlog. Veel minder vaak bezit die product backlog ook zijn voornaamste eigenschappen, aangeduid met het acroniem DEEP (Detailed appropriately, Estimated, Emergent, Prioritised). Als je de product backlog ziet als de lijst met requirements waaraan het systeem moet voldoen, gaat het al snel lijken op een traditionele baseline van requirements. Je bent dan namelijk al snel geneigd om vooruit te werken, te veel informatie vast te leggen en requirements (of user stories) te laten goedkeuren. Dat is jammer, want dan ontneem je de business en het agile team de mogelijkheid om proefondervindelijk te ontdekken wat voor systeem er echt nodig is.

Een product backlog is bedoeld als actielijst. Een opsomming van nog uit te werken en nog te valideren requirements. Het uitwerken doe je kort voor de sprint en het valideren pas ná implementatie. In feite valideer je of de ontwikkelde software aan de behoeften voldoet, niet of de requirements juist zijn verwoord. Als het goed is, is er geen sprake van al gevalideerde of goedgekeurde requirements op de product backlog.

3. Sprintdoel als eerstvolgende stap

Je wil iedere sprint businesswaarde leveren en een stap dichter bij de bedrijfsdoelstelling en de productvisie komen. Een sprintdoel geeft aan waarom die sprint belangrijk is, welke stap je als team in de richting van het einddoel gaat zetten. Op deze manier voorkom je dat er in een sprint alleen onsamenhangende user stories worden geïmplementeerd. Een sprintdoel geeft het ontwikkelteam richting en zorgt ervoor dat de teamleden gaan samenwerken. Het geeft het ontwikkelteam enige flexibiliteit om mee- en tegenvallers op te vangen ten aanzien van de requirements die ze in de sprint moeten implementeren.

Het sprintdoel stel je tijdens de sprintplanning gezamenlijk vast. Het kan de overkoepelende functie van een aantal samenhangende product backlog items zijn, een risico dat je wilt uitsluiten of een aanname die je met behulp van de te ontwikkelen software wilt toetsen bij de gebruikers.


Mochten in jouw project deze must haves nog niet op orde zijn, dan zou ik daar nu prioriteit aan geven. Je kunt nog zoveel user stories uitwerken, maar zonder deze must haves is de kans groot dat de business niet het systeem gaat krijgen dat ze echt nodig heeft.

Waar liggen jouw prioriteiten op dit moment? Zijn er in jouw project andere dringende issues die je aandacht vragen of ben je al met één van bovenstaande must haves bezig? Deel het alsjeblieft in het reactieveld hieronder.

Succes met de requirements,

Nicole de Swart

PS Vond je dit artikel interessant? Deel het dan op Twitter, LinkedIn, Facebook of Google+ door op onderstaande knoppen te klikken.


Reacties (0)


Geef een reactie

Gratis preview Handboek Requirements

Cover ‘Handboek Requirements’

Lees alvast 5 hoofdstukken uit het compleet vernieuwde boek (eind augustus in de winkel)

Nicole de Swart

Nicole de Swart

Volg Nicole op:

Gratis video met tips voor user stories

Masterclass ‘Vervolmaken van je user stories’

Ontdek hoe je 5 door analisten veel gemaakte fouten omzeilt