Hvordan skrive smidige brukerhistorier: 7 retningslinjer

I utgangspunktet er smidige brukerhistorier korte, enkle verktøy for å dokumentere en enkelt handling eller intensjon ønsket av den målrettede brukeren for å oppnå et mål. De enkleste brukerhistoriene har formatet “Som en brukertype eller rolle, Jeg vil handling eller hensiktså det grunn eller fordel”Som svarer på minst tre enkle spørsmål om hvem, hva og hvorfor historien står i etterslepekøen.

Etter hvert som lag modnes og organisasjoner bruker smidige på tvers av flere lag og initiativer, får smidige brukerhistorier ofte mye mer definisjon og struktur for å sikre at det er en felles forståelse av intensjonen og de underliggende kravene.

Komme i gang med å skrive smidige brukerhistorier

Det er mange ressurser for å hjelpe nye produkteiere, forretningsanalytikere, scrum-mestere og tekniske ledere til å forstå det grunnleggende om å skrive brukerhistorier. Noen steder å starte inkluderer artikler fra Atlassian, FreeCodeCamp, Agile Modeling, og disse 200 brukerhistorieeksemplene. En av de mer komplette oppskrivningene er i Alexander Cowans beste smidige brukerhistorie. Det er bøker om historieskriving, inkludert Kartlegging av brukerhistorieav Jeff Paton og Peter Economy og Brukerhistorier bruktav Mike Cohn. Du kan også ta kurs om historieskriving fra Udemy, Learning Tree, VersionOne og Lynda.

Et grunnleggende prinsipp som Bill Wake først delte, er å invester i gode historier. Investerestår for "uavhengig, omsettelig, verdifull, estimerbar, liten og testbar", som utgjør en god sjekkliste for smidige historieforfattere. “En smidig lederveiledning for å skrive brukerhistorier” er en artikkel som forklarer hvordan du søker investereprinsipper.

Det grunnleggende er relativt enkelt, men jeg hører ofte og ser at jeg kobler fra interessenter, produkteiere, utviklere og testere rundt kvaliteten på kravene eller om en historie virkelig er gjort. Noen ganger er det motstridende synspunkter på detaljnivået som kreves, hvor de skal passe inn i tekniske krav, og hvilke gjenstander som skal opprettes med brukerhistorier.

Med disse spørsmålene i bakhodet, er det sju retningslinjer for grunnleggende skriving av smidige brukerhistorier.

1. Skriv historier for publikum som vil bruke dem

Før du skriver historier, må du huske at historier er ment å bli lest og forstått av mennesker som deltar i utviklingsprosessen med forskjellige behov og ansvarsområder. Historieforfattere og bidragsytere bør holde publikum i tankene og utarbeide historier for å imøtekomme de kollektive behovene:

• Produkteiere er kanskje ikke de som skriver historiene, spesielt hvis organisasjonen din delegerer denne funksjonen til forretningsanalytikere, eller hvis det er flere som er involvert i historisk skriving. Produkteiere vil sørge for at historien fanger brukerens behov og hensikter fullt ut. De bør lese gjennom de detaljerte akseptkriteriene, men ønsker ikke nødvendigvis å være full av tekniske implementeringsdetaljer. Produkteiere bør også forstå hvordan historien er tilpasset det større bildet, så de må ta en aktiv interesse i hvordan epics og funksjoner blir definert og hvordan historier blir tildelt dem.
• Interessenter vil ikke lese historiedetaljene, men vil bore ned fra epos og lese historiens sammendrag. Hvis du har mange interessenter, bør du vurdere å bruke et beskrivende format for sammendrag og flytte "Som en brukertype eller rolle”Beskrivelse til starten av brukerhistoribeskrivelsen.
• Tekniske potensielle kunder er ofte den første personen fra teamet som gjennomgår historier, og de vil studere kravene for å se om en historie er for stor og bør deles i flere historier, eller se om historien trenger teknisk forhåndsarbeid for å bestemme det beste løsning.
• Ansvarlig er den ansvarlige for å gjennomgå detaljene og rapportere om fremdriften på daglige standupmøter. Tilordnede bør gjennomgå historier for avhengigheter som kan bli blokker i løpet av sprinten.
• Teammedlemmer går ofte gjennom alle historiene for å forstå deres tildelte historier i sammenheng med andre historier som er tildelt sprinten.
• Testere avgjør om det er hull eller risikoer som ikke er identifisert i akseptkriteriene, og vurderer deretter hvordan de best kan implementeres i automatiserte testrammer.
• Teamets analytiker, som kan være programleder eller medlem av prosjektledelseskontoret, vil ha historier som er fullstendig merket og kategorisert slik at meningsfylte beregninger kan trekkes fra etterslepet.

2. Begynn med brukeren i tankene

Selv om smidige brukerhistorier kan kreve mange detaljer, er det veldig viktig å begynne med brukeren i tankene. Historien skal være definerende hvahandling eller hensikt brukeren ønsker å oppnå og Hvorfordette adresserer et behov, en kjerneverdi eller et mål som er hentet fra opplevelsen.

For mer komplekse applikasjoner er det viktig å definere forskjellige brukerpersoner som illustrerer behov, verdier og bruksmønstre for forskjellige brukertyper og kan forbedre historisk skriving. I "10 tips for å skrive gode brukerhistorier" foreslår Roman Pichler at "personamålene hjelper deg med å oppdage de riktige historiene. Spør deg selv hvilken funksjonalitet produktet skal gi for å oppfylle personas mål. ” Å bruke personas for å styrke brukermålene gir en rikere betydning av Hvorforen historie er viktig og hjelper til med å prioritere etterslepet.

3. Svar på hvorfor historien er viktig

Å forstå, dokumentere og diskutere brukerbehov eller brukerpersonamål er bare en dimensjon rundt Hvorforprodukteieren prioriterer historier. Historien skal også gi forretningsverdi, noe som er vanskelig å tallfeste, men som kan være kvalifiserbarpå historien, innslag, episk eller utgivelsesnivå.

Svarer Hvorforkan være viktig for utviklerne når de har tillatelse til å foreslå forskjellige implementeringsalternativer. For eksempel kan en funksjon som forbedrer påloggingsopplevelsen for brukere også være til nytte for virksomheten hvis den nye opplevelsen også genererer bedre kundedata. En utvikler kan reflektere over denne merverdien og optimalisere implementeringen for dette målet, selv om historiens akseptkriterier ikke er spesifikke for dette kravet.

4. Definer akseptkriterier uten å foreskrive en løsning

Den viktigste disiplinen å fokusere på i historisk skriving er i utarbeidelse av akseptkriterier. Dette er ofte punktlister over korte pass-or-fail-utsagn som dokumenterer krav, begrensninger, beregninger og forventninger. Disse akseptkriteriene brukes ofte på flere måter:

• Tekniske ledere og team bruker dem til å estimere historiepoeng basert på kompleksitet og innsats.
• Utviklere begrenser implementeringsalternativene til de som oppfyller akseptkriteriene.
• Produkteiere kan redusere omfanget eller kompleksiteten av akseptkriteriene for å drive implementeringer med lavere estimater.
• Tilordneren kommuniserer blokker eller problemer som oppfyller vanskelige kriterier under standups.
• Kvalitetssikringsingeniører bruker akseptkriterier for å utvikle automatiserte tester.
• Produkteieren vurderer viktige kriterier under den smidige demoen for å sikre at historien er ferdig.

Å skrive akseptkriterier er ikke trivielt. Akseptkriterier for akseptkriterier fremhever noen av problemene, for eksempel å tilby for mange kriterier, definere kriterier som er for vage eller dokumentere komplekse kriterier som ikke lett kan verifiseres. Noen forfattere bruker maler for akseptkriterier som definerer en struktur for korte, atomare og testbare kriterier.

5. Bruk historier for å definere hva og hvorfor; definere oppgaver for hvordan de skal implementeres

En av de kritiske feilene jeg ser at lag gjør rundt historisk skriving, er å være utførlig og spesifikk rundt implementeringen. Disse dårlig skrevne historiene investerer mye arbeid i å beskrive hvordanå implementere ofte på bekostning av beskrivelsen hvabrukeren trenger, Hvorforden adresserer målene deres, og hvordet driver forretningsverdi.

Det er noen grunner til at dette kan skje.

Uerfarne produkteiere kan bruke historier til å male implementeringsvisjonene. Med andre ord kan de spesifisere brukerdesign og funksjonelle implementeringer i stedet for å dele målbrukeropplevelsen og fordelene. Noen produkteiere forvirrer konseptualiseringen av hvordan noe kanskjearbeide (prosessen der de kommer til å forstå kravene) med hvordan det børarbeid, ved et uhell å gjøre et internt implementeringseksempel til en ekstern implementeringsspesifikasjon.

Andre produkteiere kan overskride grensene ved å be teamet "bygge meg dette." Det er en av mine 20 dårlige oppførsel fra produkteiere, som jeg har anbefalinger til produkteiere om å samarbeide med teamet rundt løsninger.

Den andre grunnen til at historier kan bli rotete med implementeringsdetaljer, er at noen team og tekniske ledere vil ha dette detaljnivået. Nydannede tekniske team som jobber med å forbedre eksisterende applikasjoner, kan ønske seg dette detaljnivået til de bedre forstår hvordan applikasjonen fungerer og fullt ut forstår brukernes behov. Noen distribuerte team som jobber med offshore-utviklere eller frilansere, vil kanskje også dokumentere implementeringsdetaljene for å sikre at disse medlemmene forstår deres ansvar.

For slike team er det beste å koble til implementeringsdiagrammer og dokumentere hvem som gjør hva og hvordan som oppgaver knyttet til historien. De fleste smidige styringsverktøy tillater oppgaver eller underoppgaver, og dette detaljnivået er vanligvis skilt fra historien. Et diagram i dette innlegget gjør en god jobb som illustrerer dette viktige prinsippet om å bruke smidige historier for å bryte ned brukeropplevelser og forretningsprosesser og legge til oppgaver for å definere implementeringen til individuelle arbeidsoppgaver.

6. Merk historiene dine for å drive analyser og øve forbedringer

Når historier er skrevet, jobbet og fullført, ser mange team på å fange beregninger og utføre analyser som kan føre til prosessforbedring eller brukes til å lage forretningssaker for ekstra investering.

Her er noen eksempler:

• Merk historier som teknisk gjeld for å kvantifisere gjeldens størrelse, prosentandelen av lagets hastighet som brukes til å adressere den, og den totale gjelden fullført med hver utgivelse.
• Definer funksjonelle og tekniske topphistorier for å stimulere eksperimentering og innovasjon, og rapporter deretter hvor det har innvirkning på virksomheten.
• Hvis teamet ditt estimerer smidige brukerhistorier, kan du be teamet om å merke historier på slutten av sprinten for å signalisere om de overvurderte eller undervurderte for å forbedre nøyaktigheten av estimatene.
• Bruk etiketter, komponenter og egendefinerte felt for å søke i etterslaget etter historisk forståelse eller beregninger. For eksempel å vite hvilke historier som påvirket API-ene eller hvilke krav som førte til de siste funksjonelle forbedringene til et bestemt område av applikasjonen, kan gjøres når historier er merket med funksjonelle og tekniske komponenter.
• Merk historier som samler inn eller behandler sensitiv informasjon som personlig identifiserbar informasjon (PII), e-handelstransaksjoner eller bransjeregulerte data som HIPAA-data for å muliggjøre sikkerhet og gjennomgang av samsvar.
• Gi tilbakemelding til produkteieren og teamet. Utover å markere en historie ferdig, kan en produkteier også gi tilbakemelding til teamet, for eksempel å anerkjenne en god jobb. På samme måte kan teamet gi tilbakemelding til produkteieren om den generelle kvaliteten og tolkbarheten til en brukerhistorie.

7. Definer smidige historiemaler og stilguider

Større organisasjoner som jobber med flere smidige team og produkteiere, vil kanskje utarbeide standarder og stilguider for historisk skriving. Konsistensen hjelper nye produkteiere å lære seg skriveferdighetene raskere og forbedrer også teammedlemmers effektivitet i å konsumere informasjonen.

En annen grunn til å designe historiemaler er at forskjellige typer produkter og applikasjoner egner seg til forskjellige brukerhistoriske uttrykk og gjenstander. Noen eksempler:

• Forretningsprosesshistorier kan kreve lenker til arbeidsflytskjemaer og også spesifisere roller og tillatelser.
• Kundevendte applikasjonshistorier bør ha lenker til trådrammer og inkludere ytelseskriterier.
• API-historier bør dokumentere forventede bruksmønstre og beregninger.
• Bedriftsintelligens og datavisualiseringshistorier bør gi retningslinjer rundt hvilke felt og informasjon som trengs for den forespurte analysen.

Maler hjelper med å bygge bro over kommunikasjonen mellom team og produkteiere om hva du skal fokusere på når du skriver smidige historier.

Og er ikke det poenget med smidige historier? Agile historier om skriving, retningslinjer og prinsipper er der for å hjelpe teamene å vite hva som er viktig for brukerne og for virksomheten før de vurderer hvordan de skal implementere.