Hur skriver vi effektiva användarhistorier?
det finns 5 vägledande principer som jag rekommenderar följande:
- Alla ska vara glada
att få alla ombord är viktigt, så få alla som kommer att skriva och använda dina användarhistorier för att mata in sina idéer och komma överens om det format du alla använder. - var konsekvent
När du har en överenskommen struktur, se till att du håller dig till den. - fokusera på vad som är viktigt
När du skriver ut dem, undvik oviktiga detaljer., Ta dig tid att göra dem koncisa, ta bort alla våffla som det bara blir i vägen. - inga implementeringsdetaljer
fokusera alltid på ”varför” inte ”hur”. Varför vill en användare ha något, inte hur ska vi bygga det. Om du behöver ange tekniska detaljer bör dessa bifogas som separat spec-fil. - klar, genomförbar &testbar
se till att alla kan förstå varje berättelse och att det är möjligt i den tidsram du är nöjd med. Om du levererar i 2 veckors sprints, bör det inte ta längre tid än de 2 veckorna.,
användarhistoria anatomi
det finns 3 obligatoriska delar till en användarhistoria, titel, beskrivning och acceptanskriterier. Ditt team kan komma överens om att en användarberättelse måste ha andra fält innan arbetet kan starta på det. Till exempel kan du kräva en uppdragstagare, storypoints eller affärseffekten, men jag anser att dessa är frivilliga eftersom inte alla organisationer kommer att kräva dessa.
Titel
titlar ska vara korta, unika och inte vilseledande.,
några bra exempel:
- ”Lägg kontakta oss panel till hemsidan”
- ”Lägg betalkort stöd Till kundvagnen”
- ”uppdatera e — mall taggning”
några mindre bra (tyvärr verkliga världen) exempel:
- ”gör överenskomna ändringar”
- ”32072 – uppdaterad kartläggning — Upsell användarberättelse (27263)”
- ”links-Tracking query string for Bill trigger and smart post install …”
beskrivning
beskrivningen innehåller den verkliga kraften i användarhistorien. Det bör skapa empati i laget för användaren och en förståelse för problemet som ska lösas.,
en mycket populär struktur för beskrivningen har formen av ”som en … Jag vill … så jag kan …”.
den här strukturen frågar frågan om”som en vem”? Vem är användaren inför problemet? Du kan referera till en persona här om du använder dem, alternativt ge användaren ett namn och lägga till några sammanhang i användarens situation. Försök att undvika att använda ”som kund” eller ”som användare” eftersom detta är mindre effektivt för att skapa empati för en verklig användare.
beskrivningen ska skrivas på ett enkelt, tydligt språk, utan tekniska termer eller förkortningar., Du borde fråga dig själv ” kan din Nan förstå det?”En ny teammedlem ska kunna läsa beskrivningen och förstå exakt vad problemet är som måste lösas.
följande verkliga exempel tas från ett projekt för att lägga till funktionalitet till ett online-kontosystem för kunder i ett brittiskt energiföretag.,
några bra exempel:
- ”som John, en kund med en traditionell elmätare, vill jag förstå varför jag inte kan se diagram över min energianvändning mer detaljerat än månad för månad så jag kan bestämma om jag vill ändra detta och få en smart mätare installerad.”
- ” som Bart, en proaktiv traditionell mätarkund som vill se till att min nästa räkning är korrekt, vill jag veta om en mätarläsning redan har lämnats in idag och att jag inte behöver skicka in en annan.,”
några mindre bra exempel:
- ”som användare vill jag förhindra att trad-kunder kan borra ner under den högsta nivån så att deras kundupplevelse hanteras”
- ” som kund som antingen har tillhandahållit en mätare läst idag eller hade ett bränsleläst uppskattat idag, ska jag inte tillåtas att skicka in en annan mätare läs idag eftersom SAP inte kan acceptera mer än en mätare läs per bränsle per dag.”
de mindre bra exemplen skrevs faktiskt om för att vara de goda exemplen ovan eftersom de problem som de skisserade inte var tydliga., Denna förfining process bör göras när som helst någon del av en användarhistoria är inte klart. Se bara till att alla i laget är medvetna om och samtycker till ändringarna.
acceptanskriterier
acceptanskriterier används för att bevisa att användarhistoriken är fullständig. Detta är till hjälp för utvecklare och testare.
skriva acceptanskriterier är ett effektivt sätt att gå igenom alla detaljer i historien innan du börjar något arbete. Många potentiella fallgropar eller oväntat arbete kan ”upptäckas” tidigt genom att skriva bra acceptanskriterier.,
en mycket populär struktur för godkännandekriterierna har formen av ”Given… När… då…” som framgår av exemplen nedan.
om en användarhistoria har mer än 10 acceptanskriterier kan det vara en indikation på att historien gör för många saker. I det här fallet rekommenderar jag att du överväger att dela upp historien.
hela teamet bör delta i skrivandet av acceptanskriterierna. Om detta inte är möjligt rekommenderar jag starkt att alla läser och samtycker till dem innan de arbetar med dem. Detta gäller särskilt för alla som är involverade i att testa arbetet.,
genom att numrera acceptanskriterierna blir det enkelt att referera till dem.
några bra exempel:
- ges en kund med en traditionell mätare på energianvändningsfältet diagrammet
När du klickar på verktygstips för en månad
sedan visas en popup som matchar den angivna designen. - med tanke på en dubbelbränslekund som tittar på energianvändningsfältet
när de har månader med uppskattade värden
ska diagramlegenden tydligt visa en uppskattad Elikon med en ljus röd stapel
då ska diagramlegenden tydligt visa en uppskattad gasikon med en ljusblå stapel.,
när vi inte behöver användarhistorier
tekniska uppgifter
Ibland verkar en teknisk uppgift inte relatera till en kund. Om så är fallet, använd inte en användarhistoria. Men det är alltid värt att överväga varför du gör en teknisk uppgift; uppgraderar du ett bibliotek för att förbättra hastigheten för användarna? Om så är fallet bör det vara en användarhistoria.
buggar
om en bugg hittas under testningen av en användarhistoria som för närvarande arbetar med, bör den associeras med den användarhistorien.,
ör inte associeras med en användarhistoria utan läggas till eftersläpningen som en självständig uppgift.
kontinuerlig förbättring
användarhistorier kommer att utvecklas eftersom mer lärs om det arbete som ska göras. Det här är bra, fortsätt att förbättra dem ända fram till den punkt du släpper arbetet till användarna., Se bara till att alla i ditt team är medvetna om och samtycker till eventuella ändringar som görs.
Fortsätt förfina processen. Var smidig, reflektera över hur dina användarhistorier fungerar för ditt lag, diskutera dem i retros och fortsätt att förbättra hur du skriver dem.
Lämna ett svar