Användarberättelser och iterationsplanering

En användarberättelse (user story) är en kort beskrivning av något en användare behöver, skriven ur användarens perspektiv. Iterationsplanering är hur ett team bestämmer vilka stories det ska arbeta med under nästa tidsbox. Många team kallar den tidsboxen en sprint och mötet sprintplanering; East Agile Tracker kallar dem iterationer och iterationsplanering.

Vad en användarberättelse är

Den vanliga mallen är:

Som [typ av användare] vill jag [någon förmåga], så att [någon nytta].

Till exempel: Som projektledare vill jag se vilka stories som är blockerade, så att jag kan lösa dem innan iterationen tar slut.

Mallen anger vem som har nytta av något, vad hen behöver och varför. “Varför” gör att teamet kan hitta ett enklare sätt att leverera samma nytta. En story är en platshållare för ett samtal, inte en fullständig specifikation: detaljerna arbetas fram mellan de som efterfrågar och de som bygger.

INVEST: är storyn redo?

INVEST är en checklista för en välformad story:

• Independent (oberoende) — kan byggas och levereras för sig själv.
• Negotiable (förhandlingsbar) — detaljerna är öppna för diskussion.
• Valuable (värdefull) — levererar något som en användare eller kund bryr sig om.
• Estimable (estimerbar) — teamet förstår den tillräckligt väl för att bedöma storleken.
• Small (liten) — ryms med god marginal inom en iteration.
• Testable (testbar) — det finns ett tydligt sätt att avgöra att den är klar.

Acceptanskriterier

Acceptanskriterier anger vad som måste vara sant för att storyn ska räknas som klar. Skrivs de i formen Given / When / Then blir varje kriterium ett acceptanstest:

Given en story med en olöst blockerare, when jag öppnar kolumnen Blocked, then listas storyn där.

Kriterierna bestäms innan arbetet börjar, så att teamet och den som accepterar storyn har samma definition av klart.

Iterationsplanering

Iterationsplanering besvarar en fråga: vad ska vi arbeta med under den här iterationen? Den behöver tre underlag:

1. En ordnad backlog — stories rangordnade efter prioritet, där de översta är redo (de uppfyller INVEST och har acceptanskriterier).
2. Estimat — varje kandidatstory storleksbedömd i story points.
3. Velocity — hur många poäng teamet slutför per iteration. Se Vad är velocity?.

Teamet tar stories från toppen av backloggen tills summan når dess velocity. Att ta på sig mer än så förutsätter att teamet plötsligt arbetar snabbare; att ta på sig mindre lämnar kapacitet outnyttjad.

Så gör East Agile Tracker

• Stories finns i fyra typer: features, bugs, chores och releaser. Som standard tar bara features poäng. Se Stories.
• Acceptanskriterierna skrivs i beskrivningen. Det finns inget separat fält; kriterierna hör hemma i beskrivningen innan storyn startas. När en story är levererad accepterar eller avvisar produktägaren den mot de kriterierna. Se tillståndsmaskinen och acceptansloopen.
• Backloggen är en enda strikt ordnad lista, och den projicerar de kommande iterationerna utifrån velocity, tre eller fyra framåt, och markerar varje grupp som överskrider velocity. Se Iterationer.
• Iterationsplaneringen sker till stor del automatiskt. Med auto-plan iterations på (standard) fylls den aktuella iterationen upp till din velocity; drar du in en ny story flyttas den med lägst prioritet tillbaka till toppen av Backlog. Team som åtar sig en fast omfattning, i Scrum-stil, kan stänga av auto-plan och planera så mycket de vill, med en räknare som blir röd över velocity. Se Planera en iteration.
• Att skapa en story öppnar en redigerare för titel, beskrivning, typ, estimat och ägare. Se Skapa en story.

Läs vidare

• Vad är story points? — att storleksbedöma stories.
• Vad är velocity? — kapacitetssidan av planeringen.
• eXtreme Programming — där användarberättelser och planning game kommer ifrån.