Jag ser User Stories överallt

Jag ser User Stories överallt. Eller snarare Behovet av User Stories. I en av mina tidigare bloggartiklar pratade jag om vissa essentiella kravelement: vilka attribut måste vara sammankopplade med en "kravtext" för att man ska kunna förstå VAD som är tänkt att förmedlas? Hur ser formatet ut för den minsta möjliga kunskapsenheten för en lyckad kommunikation?

Om man hittar en inköpslista på golvet i snabbköpet, har den inget generellt värde, men kan vara oerhört viktig för personen som skrev den. På samma sätt så kan vi inte "plocka upp" krav som saknar en ansvarig källa, en aktör, någon som är ansvarig för påståendet i egenskap av en roll eller som representant för en grupp (intressentklass, persona, etc.), det vill säga, någon som tydliggör från vilket håll man tittat på verkligheten när man formulerade kravet.

Med liknande resonemang kan vi se på rationalen, den ofta "pratiga" förklaringen kring varför vi valt att formulera det specifika önskemålet/kravet. Och samma sak gäller för våra ofta internaliserade villkor (conditions of satisfaction) kring kravet: hur ser situationen ut där vi korkar upp "den virtuella champagnen", när kommer vi bli nöjda med det vi påstått att vi vill ha?

Denna kvadrupel (vyn, kravet, rationalen, nöjdhetsvillkoren) är i min mening atomär - det är den minsta möjliga kunskapsenheten.

När varje påstående passserar dessa fyra portar, blir kommunikationen helt enkelt tydligare. Dessa kunskapsenheter är som foton tagna från specifika platser av en viss person, med linsen riktad i en given riktning, vid en viss tidpunkt och ett visst datum och årtal. Alla dessa snapshots skulle kunna pusslas ihop till en fascinerande 3D modell. En del foton kommer att vara detaljerade och andra mer generella, men alla hänger ihop.

Hur många behövs? Vi behöver så många att vi kan navigera tillräckligt bra. Varken mer eller mindre.

Vi behöver inte foton från varje meter, om vi ska åka från Göteborg till Karlstad. Men kanske ett foto från varje större korsning, några tydliga kännetecknande vyer (exempelvis skidbacken i Ale) och definitivt några bilder på platsen i Karlstad som vi menar representerar "framme".

User Story-formatet behöver inte begränsas till krav på ett tänkt IT-system. Jag har använt formatet på helt andra situationer där jag velat definiera en lägsta nivå för kommunikation kring de respektive kunskapselementen. Exempelvis har jag skapat "Risk Story Cards" för att definiera tydliga risker, en "Project Story" för att enkelt definiera projektets drivkrafter, "Decision Story Cards" för att bättre förstå beslut, "Coaching Story Cards" för att bättre förstå behovet av en specifik coachinginsats. Jag använde User Story-formatet som en bas, men modifierades den med ytterligare information för att ännu bättre passa in i och verka i den specifika situationen i projektet. 

Om vi pratar User Stories blir kommunikationen mer precis och varje story blir en tydlig del av uppbyggnaden av den interna förståelsen av världen, vad som sägs och vad som händer.

Så nästa gång du hör ett påstående, försök att lotsa det igenom de fyra portarna (vyn, ”själva krav-påståendet”, rationalen, nöjdhetsvillkoren) så kommer du direkt märka en skillnad.

 

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.