Brukerhistorier er ikke en kravspesifikasjon

Viktigheten av et godt forstått, prioritert og avtalt sett med krav er innlysende. Forsøk på å definere et fullstendig og detaljert sett med krav for tidlig i et prosjekt viser seg imidlertid å være kontraproduktivt, restriktivt og sløsing. Forretningskrav er komplekse og stadig skiftende. Det er ikke mulig å definere alle de detaljerte kravene i begynnelsen av et langt prosjekt.

Brukerhistorier er sannsynligvis den mest populære smidige teknikken for å beskrive ønsket funksjonalitet: Det er derfor en vanlig misforståelse å tenke at en liste med brukerhistorier er det samme som kravspesifikasjonen til et produkt eller prosjekt. Tanken er fristende fordi den lar oss mentalt overføre tradisjonell kravspesifikasjon for programvare til Scrum-metodens backlog som består av brukerhistorier.  Men en brukerhistorie er ikke et krav.  Det er bedre å tenke på en brukerhistorie som en «peker» til et krav. Gjennom å beskrive typiske brukerhistorier hjelper man prosjektteamet med å forstå behovet som er grunnlag for kravet.

    En brukerhistorie kan i praksis være utgangspunktet for en samtale, der teammedlemmer tar en historie som skal jobbes med, går bort til produkteierens skrivebord og sier  «Fortell oss mer». Det er i den samtalen kravet defineres.  Den skrevne brukerhistorien i backlogen var bare en henvisning til samtalen.  Den var enkelt sagt en påminnelse for teamet om å ha samtalen. 

      Ikke alle brukerhistoriene henviser til denne type samtaler.  Noen historier kan henvise til:

      • Regneark med eksempler på beregninger
      • Algoritmer eller pseudokode
      • Flytskjema eller diagrammer som viser en arbeidsflyt
      • Brukergrensesnittdesign som viser hvordan noe skal se ut når det er implementert
      • Og mye annet

      Brukerhistorier, som brukes for å lage en backlog for produktet eller prosjektet, er derfor ikke godt egnet til å være en kravspesifikasjon i tradisjonell forstand.

        Hvis teammedlemmer begynner å tenke på hver brukerhistorie som et krav i seg selv, resulterer det ofte i at de gjør prosjektet mindre smidig totalt sett. Ved i stedet å tenke på hver historie som en peker til et krav kan hjelpe teamet å lykkes med smidige metoder.

          Legg igjen en kommentar

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