In dit artikel worden de Product Backlog – Epics en User Stories beschreven. Epics en User Stories zijn beschrijvingen van klantbehoeften, die je wilt opnemen in de sprint.
Product Backlog User Stories is een onderdeel van de Product Backlog welke hier is beschreven
Wat zijn Product Backlog User Stories?
In User Stories staat voor wie er wat gemaakt moet worden en waarom. De beschrijving is in begrijpelijke taal en geschreven vanuit een gebruikers perspectief. In tegenstelling tot wat men vaak verwacht mogen User Stories ook vanuit een Stakeholder perspectief geschreven worden.
Wat is een Epic?
Een Epic is een User Story die nog niet voldoende uitgewerkt is. Kortom, een grotere User Story waarvan het team niet kan bepalen wat er moet worden opgeleverd en dus ook nog niet kan inschatten hoeveel werk het is.
Een Epic moet verduidelijkt worden in kleinere User Stories.
Van Epic naar User Story
In de literatuur staat de volgende omschrijving:
As who, I want what so that why
Dat lijkt wat cryptisch, maar is eigenlijk heel eenvoudig.
Ik behandel hieronder een eenvoudig en sterk versimpeld voorbeeld om dat verder uit te leggen:
EPIC ‘bestellen’:
Als [KLANT] wil ik [EEN STOEL KUNNEN BESTELLEN] zodat ik [LEKKER KAN ZITTEN ZONDER DAT IK DE DEUR UIT MOET].
USER STORY ‘bestellen’:
Als [KLANT] wil ik [VIA EEN WEBSITE MIJN STOEL KUNNEN BESTELLEN] zodat ik [DE STOEL BEZORGD KRIJG DIE IK WIL HEBBEN].
Wanneer is een User Story duidelijk?
Een user story is duidelijk wanneer het Scrum Team gezamenlijk hetzelfde begrip hebben.
Als de volgende methode gebruik wordt is er sneller overeenstemming over een User Story, de methode heet INVEST
Stories should be INVEST
I Independent: voorkeur voor niet overlappende Stories die onafhankelijk van elkaar kunnen worden gerangschikt.
N Negotiable: Pak de essentie, voeg details toe tijdens de implementatie.
V Valuable: moet van waarde zijn voor de klant (is altijd van toepassing bij alle agile werkzaamheden).
E Estimatable: Het team moet de story kunnen schatten, precies genoeg om op te pakken en te realiseren.
S Small: kleine Stories zijn beter, een Story mag niet de sprint overschrijden, meerdere Stories per Sprint is beter.
T Testable: een klant moet in staat zijn om de Story te testen, een test vroeg schrijven is goed.
Acceptatie Criteria
In voorgaande alinea gingen we uit van de ‘gewone’ klantwensen en klanteisen. Er is echter ook nog een andere categorie, dit zijn de algemeen geldende of specifieke (organisatie) richtlijnen die gelden voor alle User Stories. De acceptatie criteria (Acceptance Criteria).
Voordat een User Story kan worden opgepakt of opgeleverd, moet voldaan zijn aan de richtlijnen van Acceptatie Criteria.
Acceptatie Criteria zijn (gedetailleerde) voorschriften waar aan voldaan moet worden. Ook de Acceptatie Criteria behoren in eenvoudig taalgebruik beschreven te zijn. Er mag geen enkele onduidelijkheid zijn die zou kunnen leiden tot misverstanden.
Veelal zijn het (zeer) gedetailleerde eisen welke niet onderhandelbaar zijn.
Eenvoudige voorbeelden:
- Gebruiker kan niet verder met de volgende stap als niet alle verplichte velden van het formulier zijn ingevuld.
- Betalen alleen via iDEAL.
- Alleen leden hebben na inloggen met klantnummer en wachtwoord toegang tot de database.
Definition of Ready
Een User Story moet voldoen aan de Definition of Ready voordat deze opgenomen kan worden in de Sprint.
Voordat een User Story kan worden opgenomen in de Sprint, zal in de Sprint Planning de taken moeten worden bepaald.