Scrum Guide | 21. Fejl i brugerhistorier

Brugerhistorier beskriver, hvordan en ny produktfunktionalitet fungerer i hverdagens eller forretningssprog. Forberedelsen af dem tager dog meget tid, kræfter og overvejelser. I dagens indlæg påpeger vi de mest almindelige fejl i brugerhistorier og foreslår, hvordan man kan håndtere dem.

De mest almindelige fejl i brugerhistorier – indholdsfortegnelse:

1. Introduktion
2. Problemer med 3W
3. Problemer med 3C
4. Fejl i brugerhistorier – Resumé

Introduktion

Brugerhistorier kan være et fantastisk værktøj til at motivere teamet til at foreslå nye løsninger på problemer præsenteret fra brugerens perspektiv. Vi har skrevet om, hvad en brugerhistorie er i et separat indlæg. Og i denne artikel introducerede vi INVEST, som er en populær metode til at skrive gode brugerhistorier. I dag vil vi fokusere på fejl i brugerhistorier.

Problemer med 3W

En ordentlig brugerhistorie besvarer spørgsmålene:

• Hvem? (Hvem er den målrettede bruger af produktet?)
• Hvad? (Hvilke funktioner har produktet, og hvad kan det gøre?)
• Hvorfor? (Hvilket formål tjener det?)

Problemer kan dog følge med svarene på hvert af disse spørgsmål. Det mindst almindelige problem er tvivlen om hvad der skal ændres i produktet som svar på kundens behov. Derfor vil vi fokusere på problemer vedrørende Hvem? og Hvorfor?

Hvem – brugerpersona

En af de mest almindelige fejl, der begås, når man opretter brugerhistorier, er ikke at besvare spørgsmålet præcist nok: for hvem? Med andre ord, hvem er brugeren, som den planlagte ændring er beregnet til?

Ofte er et generisk svar, der peger på kunden eller slutbrugeren som modtageren af ændringen, ikke nok. Løsningen på dette problem er at forestille sig modtageren som en specifik persona. En persona er et modelbillede af den målrettede kunde. Med andre ord er en persona en repræsentation af den person, der vil bruge produktet på en specifik måde.

Efter at have analyseret din brugerhistorie, kan du finde ud af, at den fortæller historier om forskellige mennesker på samme tid. Hvis der er mange målbrugere, er det værd at overveje at opdele brugerhistorien i mindre fragmenter for at undgå modstridende, gensidigt udelukkende eller simpelthen ineffektive handlinger.

Hvorfor? – et dårligt defineret mål

Nogle gange bliver den sidste sektion af brugerhistorien kilden til problemer. Den bør specificere den forretningsværdi af de ændringer, der foretages under udførelsen af brugerhistorien. Tag et kig på et eksempel på fejl i brugerhistorier, hvor beskrivelsen af yderligere funktionalitet erstatter målet:

Som kunde vil jeg købe en tryllestav med ét klik, fordi jeg vil købe et flyvende tæppe næste uge.

I stedet for at give grunden til at købe tryllestaven, tilføjer denne brugerhistorie et andet punkt til den potentielle kundes indkøbsliste. Derfor, når du forbereder en brugerhistorie, må du ikke glemme grundene til ændringer i produktets funktionalitet.

Problemer med 3C

Vi kan opdele processen med at arbejde med brugerhistorier i tre faser kaldet 3Cs:

• Kort – Kortet, hvor brugerhistorien er gemt
• Samtale – En samtale inden for Scrum-teamet om brugerhistoriekortet
• Bekræftelse – definere acceptkriterier, der bekræfter, at en opgave er afsluttet

Fejl kan opstå i nogen af disse, som vi beskriver nedenfor.

Kort

Det hukommelseskort, der gemmer brugerhistorien, har en begrænset kapacitet. Derfor vedrører de mest almindelige problemer længden og volumen af brugerhistorien. Brugerhistorien har brug for sammenhæng og ingen omsvøb, som man siger, til en så præcis grad, at hvert ord tæller.

Dette skyldes, at problemet med brugerhistoriekortet har to dimensioner. Den ene er måden, det er formuleret på: kortfattet og indeholdende et nødvendigt minimum af opregning. Den anden er den faktiske størrelse af brugerhistorien. En generel sætning kan udtrykke et stort antal opgaver, der ikke kan gennemføres i løbet af en enkelt sprint.

Samtale

Den en-sætningsformulering af brugerhistorien er udgangspunktet for en samtale med udviklingsteamet. Derfor er det forkert at behandle det som en beskrivelse af den opgave, der skal udføres. Det forhindrer muligheden for forhandlinger og diskussion om forskellige måder at implementere den på. Brugerhistorien bør ikke betragtes som en beskrivelse af krav til ny produktfunktionalitet, det er snarere en invitation til at starte en samtale om specifikke tekniske løsninger, der vil føre til realiseringen af den forretningsværdi, der er defineret af brugerhistorien.

Bekræftelse

Vi har skrevet om acceptkriterierne, der skal defineres for hver brugerhistorie, i detaljer i teksten, der beskriver hvad en brugerhistorie er. En af de almindelige fejl er dog manglen på uklarhed i præstationskriterierne.

En veludført brugerhistorie indeholder en beskrivelse af den situation, hvori den implementeres. Dens test er, at brugeren drager fordel af den nye funktionalitet, der er skabt af udviklingsteamet.

Et nyttigt værktøj til at validere brugerhistorien er at udvikle en accepttest. Dette er normalt på den anden side af kortet, der indeholder brugerhistorien.

Fejl i brugerhistorier – Resumé

Når man forbereder og anvender brugerhistorier, er det værd at holde sig til følgende regler:

• Præcist identificere brugeren, der påvirkes af ændringen
• Klart definere formålet med at bygge ny produktfunktionalitet
• Holde dens volumen så kort som muligt
• Behandle brugerhistorien som et udgangspunkt for diskussioner med udviklingsteamet
• Etablere klare regler for accept

Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.