Bør feil beskrives som user stories?

Brukerhistorier (user stories) er et effektivt verktøy for scrum teams, men bør feil også beskrives som en brukerhistorier?

Spørsmålet kom nylig opp i en diskusjon, og det kan være interresant å se litt på hvordan vi best administrerer bugs og feilretting i et smidig utviklingsprosjekt.

    For å svare på spørsmålet om hvorvidt man bør benytte brukerhistorier for å beskrive feil man oppdager, må vi først sortere de ulike feilene i tre kategorier:

    • Feil som blir løst umiddelbart
    • Feil som vil bli løst i nåværende sprint, men ikke umiddelbart
    • Feil som ikke blir løst i nåværende sprint

    Feil som blir løst umiddelbart

    Defekter som løses umiddelbart er ofte bugs som blir funnet under arbeidet med den nåværende sprinten.  Disse trenger vanligvis ikke legges til i en backlog. I stedet kan den som fant feilen ganske enkelt si: «Jeg har oppdaget et problem i koden. Når brukeren gjør slik og så …» og en programmerer vil rette feilen umiddelbart.

      Feil som vil bli løst i nåværende sprint

      Feil som ikke kan rettes opp umiddelbart, men som vil bli løst i løpet av den aktive sprinten skal legges til sprintens backlog i stedet for backlogen til produktet.  Vi kan gjøre dette fordi sprintbackloggen inneholder alt arbeid som er planlagt for den pågående sprinten og retting av feilen er nå en del av den planen.

        Feil som ikke blir løst i nåværende sprint

        En feil som ikke blir løst i den pågående sprinten skal legges til i produktets backlog, så sant produkteier ønsker at den blir rettet i fremtiden. Men det er ikke nødvendig at disse spesifikasjonene skrives som brukerhistorier – og de trenger absolutt ikke å være etter en standardisert «Som en [type bruker] …» mal. Selv om det generelt er mange fordeler med en slik mal, er den ikke spesielt egnet til å beskrive feil.  I mange tilfeller kan det også være at bugs legges til backlogen av personer utenfor teamet, som for eksempel support eller kundeservice.  Å tillate dem å legge inn beskrivelsen av feilen i et mer naturlig språk er lettere og innholdet i feilmeldingen er vanligvis like tydelig.

          Konklusjon

          Konklusjonen blir at alle feil som skal rettes, men ikke løses i inneværende sprint bør skrives i  produktets backlog – men ikke nødvendigvis som brukerhistorier.

          Legg igjen en kommentar

          Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *