Brugerhistorier og iterationsplanlægning

En brugerhistorie (user story) er en kort beskrivelse af noget, en bruger har brug for, skrevet fra brugerens synsvinkel. Iterationsplanlægning er den måde, et team beslutter, hvilke stories det skal arbejde på i den næste tidsboks. Mange teams kalder tidsboksen en sprint og mødet sprintplanlægning; East Agile Tracker kalder dem iterationer og iterationsplanlægning.

Hvad en brugerhistorie er

Den gængse skabelon er:

Som [type bruger] vil jeg [en mulighed], så [en fordel].

For eksempel: Som projektleder vil jeg se, hvilke stories der er blokeret, så jeg kan løse dem, før iterationen slutter.

Skabelonen angiver, hvem der får gavn af noget, hvad de har brug for, og hvorfor. “Hvorfor” giver teamet mulighed for at finde en enklere måde at levere den samme fordel på. En story er en pladsholder for en samtale, ikke en fuld specifikation: detaljerne afklares mellem dem, der beder om noget, og dem, der bygger det.

INVEST: er storyen klar?

INVEST er en tjekliste for en velformet story:

• Independent (uafhængig) — kan bygges og leveres for sig selv.
• Negotiable (forhandlingsbar) — detaljerne er åbne for diskussion.
• Valuable (værdifuld) — leverer noget, en bruger eller kunde går op i.
• Estimable (estimerbar) — teamet forstår den godt nok til at vurdere størrelsen.
• Small (lille) — passer med god margin inden for én iteration.
• Testable (testbar) — der er en klar måde at afgøre, at den er færdig.

Acceptkriterier

Acceptkriterier angiver, hvad der skal være opfyldt, for at storyen tæller som færdig. Skrives de i formen Given / When / Then, bliver hvert kriterium til en accepttest:

Given en story med en uløst blokker, when jeg åbner kolonnen Blocked, then står storyen på listen dér.

Kriterierne aftales, før arbejdet begynder, så teamet og den person, der accepterer storyen, har samme definition af færdig.

Iterationsplanlægning

Iterationsplanlægning besvarer ét spørgsmål: hvad skal vi arbejde på i denne iteration? Den kræver tre input:

1. En ordnet backlog — stories rangeret efter prioritet, hvor de øverste er klar (de opfylder INVEST og har acceptkriterier).
2. Estimater — hver kandidatstory størrelsesvurderet i story points.
3. Velocity — hvor mange point teamet færdiggør pr. iteration. Se Hvad er velocity?.

Teamet tager stories fra toppen af backloggen, indtil summen når dets velocity. At tage mere end det forudsætter, at teamet pludselig arbejder hurtigere; at tage mindre lader kapacitet stå ubrugt.

Sådan gør East Agile Tracker

• Stories findes i fire typer: features, bugs, chores og releases. Som standard tager kun features point. Se Stories.
• Acceptkriterierne skrives i beskrivelsen. Der er intet separat felt; kriterierne hører hjemme i beskrivelsen, før storyen startes. Når en story er leveret, accepterer eller afviser produktejeren den ud fra de kriterier. Se tilstandsmaskinen og accept-loopet.
• Backloggen er én strengt ordnet liste, og den projicerer de kommende iterationer ud fra velocity, tre eller fire frem, og markerer enhver gruppe, der overstiger velocity. Se Iterationer.
• Iterationsplanlægningen sker stort set automatisk. Med auto-plan iterations slået til (standarden) fyldes den nuværende iteration op til din velocity; trækker du en ny story ind, flyttes den med lavest prioritet tilbage til toppen af Backlog. Teams, der forpligter sig til et fast omfang i Scrum-stil, kan slå auto-plan fra og planlægge så meget, de vil, med en tæller, der bliver rød over velocity. Se Planlægning af en iteration.
• Oprettelse af en story åbner en editor til titel, beskrivelse, type, estimat og ejere. Se Opret en story.

Læs mere

• Hvad er story points? — størrelsesvurdering af stories.
• Hvad er velocity? — kapacitetssiden af planlægningen.
• eXtreme Programming — hvor brugerhistorier og planning game stammer fra.