In een agile omgeving wordt je aangesproken op je vakmanschap. Vakmensen zijn immers professionals die zelf het beste weten hoe ze hun werk moeten uitvoeren. Dit geeft je veel vrijheid, maar ook veel verantwoordelijkheid!

Agile kent geen voorgeschreven of verplichte methoden en technieken. Alleen principes, regels en heel veel good practices.

Scrum is een procesraamwerk, geen methode. Scrum schrijft niet voor welke werkzaamheden je moet uitvoeren, welke informatie je moet vastleggen en welke technieken je daarbij kunt gebruiken. Het schept de kaders waarbinnen je zelf je werkwijze kiest.

Dit zou je kunnen vergelijken met een voetbalwedstrijd. Een elftal (inclusief coach) mag zelf bepalen hoe ze het spel spelen, zolang ze zich aan de spelregels houden. De ondertitel van de officiële Scrum Guide is niet voor niets ‘De regels van het spel’.

Analisten in een agile omgeving

Het kiezen van een geschikte werkwijze is niet altijd eenvoudig. Zeker wanneer jij of de organisatie waarin je werkt niet zoveel ervaring met agile hebben. Analisten werken vaak samen met de product owner of krijgen taken van hem gedelegeerd. Om je een vliegende start te geven, volgen hier 3 must haves waar je als agile analist of product owner aan moet denken.

1. Helder productdoel als vizier

Zorg dat vanaf het begin het productdoel en eventueel een productvisie bij iedereen bekend is. Anders weet je niet welke businesswaarde de software moet leveren. Of anders gezegd: anders kun je er niet voor zorgen dat de ontwikkelde software echt waardevol is voor de business stakeholders. En daar draait het allemaal om.

Bij veel teams zie ik dat er geregeld 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 product backlog als actielijst

In agile nemen we requirements op in een product backlog. Dit is een belangrijk stuurinstrument en het zorgt voor transparantie.

De voornaamste eigenschappen van een product backlog worden aangeduid met het acroniem DEEP (Detailed appropriately, Estimated, Emergent, Prioritised).

Een product backlog is uitdrukkelijk niet te vergelijken met een traditionele baseline van requirements. Het is niet dé lijst met requirements waaraan de te ontwikkelen software moet voldoen. Iemand die dat wel zo ziet, is al snel geneigd om vooruit te werken, te veel informatie vast te leggen en requirements (of user stories) door de business te laten goedkeuren.

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 correct zijn gespecificeerd. Als het goed is, is er geen sprake van al gevalideerde of goedgekeurde requirements op de product backlog.

Hier vertel ik je in het online programma Meester in agile requirements nog veel meer over.

3. Sprintdoel als eerstvolgende stap

Je wil iedere sprint businesswaarde leveren en een stap dichter bij het productdoel komen. Een sprintdoel geeft aan waarom de sprint belangrijk is. Welke stap je als team in de richting van het productdoel gaat zetten. Op deze manier voorkom je dat er in een sprint alleen onsamenhangende user stories worden geïmplementeerd.

Een sprintdoel geeft het agile team richting en zorgt ervoor dat de teamleden gaan samenwerken. En het geeft de ontwikkelaars enige flexibiliteit om mee- en tegenvallers op te vangen. Het sprintdoel halen is belangrijker dan alle voor die sprint afgesproken user stories volledig implementeren.

Het sprintdoel stel je gezamenlijk vast tijdens de sprintplanning. 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.

Prioriteit geven

Mochten in jouw team deze must haves nog niet op orde zijn, dan raad ik je aan om daar nu prioriteit aan geven. Zonder deze must haves is de kans groot dat de business niet het systeem krijgt dat ze echt nodig heeft. Het heeft daarom zonder deze must haves weinig zin om door te gaan met het uitwerken van user stories.

Waar liggen jouw prioriteiten op dit moment? Zijn er in jouw project andere dringende issues die je aandacht vragen? Of ben je misschien al met één van de genoemde must haves bezig? Laat het even weten via een reactie hieronder.

Nicole de Swart

Misschien vind je dit ook interessant

0 reacties

Geef een reactie