Een goede product owner of business analist is cruciaal voor een groot deel van het succes van een product. Als je de luxe hebt om voorafgaand aan de start van je rol een goede training te mogen volgen, is dat fantastisch. In de praktijk zien we vaak dat mensen ongetraind in zo’n rol (moeten) starten en zelf een manier van werken moeten ontwikkelen. Zelf werkte ik jaren in dit soort rollen en vaak moest ik op Google uitvinden wat handige werkwijzen waren. Herkenbaar? Lees dan verder …
Hoe creëer ik duidelijkheid voor mijn ontwikkelteam?
Als je product owner of business analist bent in een ontwikkelteam, heb je je vast weleens de vraag gesteld: ‘Hoe zorg ik dat de gewenste functionaliteit duidelijk is voor mijn team? Hoe zorg ik dat ik stories schrijf die duidelijke input geven aan de ontwikkelaars en testers? En hoe slice ik het werk op in handige stories?’ In deze blog vind je alvast drie tips voor het schrijven van goede stories.
Tip 1. Maak een hiërarchie van Epics, Features en Stories
Stories bevatten een gedetailleerde omschrijving van wat er gebouwd moet worden. Daarnaast is het is ook raadzaam om met een wat bredere blik naar je opdracht te kijken. Hiervoor gebruik je Features of Epics.
Een Epic omschrijft grote nieuwe ideeën die een investering vragen om ontwikkeld te kunnen worden. Een Epic duurt meestal langer dan een kwartaal om te bouwen. Bij een Epic denk je ook na over de business case: ‘Is deze oplossing deze investering waard?’
Features bouw je binnen een kwartaal en omvatten een concreet stuk functionaliteit. Hierbij kun je een zekere gelaagdheid aanbrengen in het niveau van de details en kijk je naar de Benefit die je voor je klant gaat leveren. Vervolgens splits je de feature op in een aantal Stories.
Door een hiërarchie aan te brengen in je Epics, Features en Stories, krijg je feeling met hoe groot het item dat je ontwikkelt is en welk detailniveau gewenst is. Zo kun je op story niveau toetsen aan je Epical Feature of deze story daadwerkelijk nodig is om je doel te behalen zodat je niet te veel gaat ontwikkelen. Het aanbrengen van hiërarchie helpt je met het structuren van hoofd- en bijzaken: de juiste informatie op het juiste moment.
Tip 2. Gebruik Acceptatiecriteria als onderdeel van je Story
Acceptatiecriteria omschrijven op een heldere manier voor het team het antwoord op de vraag: ‘Wat heb ik als ik deze story gebouwd heb?’ Acceptatiecriteria zijn daarom goede input voor de ontwikkelaar, maar ook voor de tester. Door acceptatiecriteria uniform en helder op te schrijven, help je je team snel te begrijpen wat de gewenste functionaliteit is. Stel; de user story syntax is:
Als werknemer wil ik veel koffie kunnen zetten, zodat ik al mijn collega’s van koffie kan voorzien.
Hierbij zouden de acceptatiecriteria kunnen zijn:
1. Het koffiezetapparaat kan <veel koffie> zetten
<veel koffie> = minimaal 12 kopjes
2. Het koffiezetapparaat kan <snel koffie zetten>
<snel koffie zetten> = 1 kopje koffie wordt in 5 seconden gezet.
Tip 3. Why, why, why, why, why …?
Het schrijven van een goede story draait natuurlijk niet alleen om het helder opschrijven van wat het product precies moet doen, maar ook dat het product de juiste waarde oplevert voor jouw klant. Dit doe je onder andere door jezelf vijf keer achtereenvolgens naar de ‘why’ van een bepaalde beslissing of actie te vragen. Waarom ontwikkelen we dit? Waarom is dit belangrijk voor onze klant? Deze vraag consequent blijven stellen zorgt ervoor dat je alleen ontwikkelt wat de klant écht gaat gebruiken. Blijf jezelf en anderen dus altijd de ‘waarom’ vraag stellen.
Meer weten over de training ‘Epics Features & Stories Schrijven’?
Wij geven hierover een praktisch toepasbare training die we graag aan laten sluiten op jouw werksituatie. Om deze reden zijn onze trainingen altijd incompany. Zo leer je met je collega’s dezelfde principes toepassen, met behulp van dezelfde tools in dezelfde taal. Dit maakt het bovendien makkelijker om naderhand samen te sparren over jullie Stories.
