I dette indlæg vil jeg gå i dybden med hvordan krav i et Scrum projekt er håndteret anderledes end ved et traditionelt projekt.
Jeg vil dermed beskrive rollen af user stories, som et normalt format for at repræsentere forretningsværdi på flere forskellige niveauer af projektet og hvordan man kan vurdere om de gældende user stories er gode eller dårlige.
Jeg vil derefter beskrive hvordan man bør håndtere ikke-funktionelle krav i et Scrum projekt. Til sidst går jeg i dybden med de to teknikker for at skaffe og skrive user stories.
Indledende
Scrum og traditionel projektledelse behandler krav meget forskelligt. Med traditionel projektledelse, er kravene ikke til forhandling, de er detaljeret up-front og skal stå alene.
I Scrum er detaljerne af kravene forhandlet gennem samtaler/workshops der finder sted kontinuerligt gennem projektet og sættes igang just in time eller just enough for at projektgrupperne kan begynde på at bygge funktionalitet for at understøtte det pågældende krav.
Med traditionel projektledelse er kravene behandlet meget på samme måde som de er ved produktion; Specifikationerne som produktet skal passe til er påkrævet og ikke til forhandling.
Disse krav er lavet up-front og givet til udviklingsgruppen i form af et meget detaljeret dokument. Det er udviklingsgruppens opgave at bygge et dokument, som lever op til disse detaljeret krav.
Når en ændring til den originale plan bliver nødvendig, så er den håndteret gennem en formel og kontrolleret ændringsproces.
Fordi overensstemmelse til kravene er målet, så er disse afvigelser uønsket og dyre. I sidste ende, så skal meget af arbejdet der er work in process, i formen af meget detaljeret krav (og alt arbejdet baseret på dem) måske ændres eller droppes.
I kontrast, så ser Scrum krav som en vigtig grad af frihed, som vi kan manipulere for at møde vores forretningsmål.
For eksempel, hvis vi løber tør for penge eller tid, så kan vi droppe low-value krav. Hvis, under udviklingen, nye informationer indikerer at cost/benefit ratioen af et krav er blevet signifikant mindre fordelagtig, så kan vi vælge at droppe dette krav fra produktet. Og hvis et nyt high-value krav opstår, så har vi muligheden for at tilføje det til produktet, måske ved at fjerne et krav der giver mindre værdi.
Vi har sikkert alle haft erfaringen med at skrive et “komplet” krav-dokument i begyndelsen af udvikling, kun for at finde ud af senere, at et vigtigt krav manglede. Når vi opdager at et krav mangler, så har samtalen sikkert mindet lidt om denne:
Kunde: “Nu da jeg kan se disse features der er bygget, så kan jeg se, at jeg mangler denne feature, som ikke er i krav-dokumentet.”
Udviklere: “Hvis du gerne vil have den feature, hvorfor specificerede du den så ikke up-front?”
Kunde: “Jamen, jeg vidste ikke at jeg har behov for den feature før jeg så produktet nærme sig at være færdigt.”
Udviklere: “Jamen, hvis du havde tænkt længere og mere over kravene up-front, så vil du have opdaget det dengang i stedet for nu.”
Faktum er, at når man udvikler innovative produkter, så kan man ikke lave et komplet dokument med alle krav eller designs up-front ved bare at arbejde længere eller hårdere.
Nogle nye krav og designs vil altid opstå når man er i gang med projektet; ingen mængde af up-front arbejde vil undgå det.
Dermed sagt, at når vi bruger Scrum, så investerer vi ikke en masse tid og penge i at beskrive alle detaljerne af et krav up-front.
Det skyldes, at vi forventer at specifikationerne vil ændre sig, som tiden går og som vi lærer mere omkring det vi bygger.
Vi undgår at overinvestere i krav, som vi måske senere hen vil droppe igen. I stedet for at samle en stor liste af detaljeret krav up-front, så skaber vi placeholders for kravene, kaldet product backlog items (PBIs). Hver product backlog item repræsenterer en ønsket forretningsværdi.
I starten af projektet er disse product backlog items store (og repræsenterer store dele af forretningsværdien) og der er kun få detaljer tildelt til dem.
Over tid kører vi disse product backlog items gennem en serie af samtaler/workshops mellem alle interessenter, product owner og udviklingsholdet, hvor vi raffinerer dem om til en samling af mindre, mere detaljerede PBIs.
Vi når så på et tidspunkt et punkt, hvor en product backlog item er så små og detaljeret at den kan føres ind i en sprint, hvor den bliver designet, bygget og testet.
Selv under sprinten vil der dog opstå flere detaljer i samtalerne mellem produktet product owner og udviklingsholdet.
Som jeg vil diskutere i et andet indlæg, så er en product backlog bare et overblik over den nuværende samling af product backlog items og deres tildelte detaljer.
Mens Scrum ikke specificerer nogen form for standard format for disse produkt backlog items, så repræsenterer mange projektgrupper PBIs som user stories.
Det behøver du ikke. Nogle projektgrupper foretrækker at bruge cases og andre vælger, at repræsenterer deres PBIs i deres egen custom format.
I dette indlæg anvender jeg user stories som den principielle repræsentation af product backlog items. Jeg vil diskutere detaljerne af user stories senere i dette indlæg.
Selv hvis du vælger at bruge noget andet, så vil du stadig finde diskussionen af user stories som værende en stor hjælp i forhold til, at forstå hvilke karakteristikker du går efter med hvilken som helst anden form for repræsentation.
Brugen af samtaler og workshops
Som et kommunikationsredskab, viser user stories en delt forståelse af, hvad der skal bygges.
De tillader alle personer som forstår hvad der skal bygges, klart at kommunikere deres ønsker til de personer, som skal udvikle det.
Traditionel projektledelse afhænger meget af de nedskrevne krav, som ser imponerende ud, men nemt kan misforstås.
Hvis man f.eks. taler med en Head of product management i en produktionsvirksomhed og spørger hvem der håndterer alle virksomhedens krav til produktionen.
Så kan svaret være noget lignende: “ d. 1 Januar giver min projektgruppe et dokument med alle kravene til ingeniør organisationen, og d. 31 December tager vi derud og ser hvad de har fået lavet.”
Derudover spørger man ind til hvilke personer der vil tilgængelige i løbet af året for at svare på spørgsmål og forklare krav for udviklerne.
Hertil ville et typisk svare være: “Ingen. Alt den tid gruppen har haft for at investere i dette projekt blev brugt på at skrive krav-dokumentet. Mine analytikere arbejder ud fra flere forskellige krav-lister for andre projekter. Men bare rolig, vi har skrevet et godt dokument, og hvilke som helst spørgsmål udviklerne har kan blive besvaret ved at læse dokumentet nøje igennem.”
Det virker dog meget usandsynligt, at der ikke vil være nogen former for uklarheder i sådan et dokument, som sagtens kan være 150 sider langt. Tekst på papir er bare ikke 100% præcist, og selv hvis det var, så er der også god sandsynlighed for, at dem der har skrevet dokumentet har lavet fejl eller ikke har formuleret sig præcist nok.
En bedre måde, at sikre at de ønskede features bliver bygget er, at sørge for at de personer der ved hvad de vil have har rettidige samtaler med de personer som designer, bygger og tester disse features.
Med Scrum udnytter vi samtaler og workshops som et vigtigt redskab for at sikre, at krav bliver ordentligt diskuteret og kommunikeret.
Verbal kommunikation har fordelen af at være høj-båndbredde og at give hurtig feedback, hvilket gør det nemmere og billigere at få en delt forståelse.
Derudover, så aktivere samtaler tovejs kommunikation som kan skabe nye ideer vedrørende problemer og muligheder – diskussioner, som ikke ville opstå fra at læse et dokument.
Samtaler og workshops, er dog bare et redskab. Det fjerner ikke alle dokumenter.
Med Scrum er et product backlog et “levende dokument”, som altid er tilgængeligt under projektet. Dem så stadig gerne vil, eller skal, have et kravspecificering dokument kan lave et når som helst bare ved at samle product backlog items og alle deres tildelte detaljer i et dokument, som de kan formatere som de ønsker.
Løbende forfining af opgaver
Med traditionel projektledelse skal alle krav være på samme niveau af detaljer på samme tid.
Specielt det godkendte kravdokument skal specificere hvert og et krav, så de projektgrupper der står for design, udvikling og test kan forstå hvordan man kan tilpasse sig til specifikationerne. Der må ikke være flere detaljer, som mangler at blive tilføjet.
Det at vinge alle krav til at have samme niveau af detaljer på samme tid har mange ulemper:
- Vi må forudse alle disse detaljer tidligt under projektet, når vi har den mindste mængde af viden om projektet vi på noget tidspunkt vil have.
- Vi behandler alle krav på samme måde uanset deres prioritet, hvilket tvinger os til at dedikere værdifulde ressourcer i dag til at skabe detaljer for krav, som vi måske aldrig kommer til at bygge.
- Vi laver en stor liste af krav, som højst sandsynligt vil være meget dyre at ændre eller fjerne, når ting ændrer sig.
- Vi reducerer chancen for at bruge samtaler og workshops til at uddybe på og klargøre krav, fordi kravene allerede er “færdige.”
Når vi bruger Scrum, så behøver alle krav ikke at have samme niveau af detaljer på samme tid.
Krav, som vi vil arbejde på tidligere vil være mere detaljeret end dem som vi ikke vil arbejde på i lang tid.
Vi igangsætter en strategi af løbende forfining af opgaver for at adskille, på en just-in-time måde, store (Epics), let detaljeret krav om til et sæt af mindre, mere detaljeret items (User Stories).
Hvad er User Stories?
User Stories er et praktisk format til at udtrykke de ønsket forretningsværdier til mange typer af product backlog items, specielt features.
User stories er lavet på en måde, som gør dem forståelige for både forretningsfolk og tekniske folk.
De er strukturelt simple og giver en god placeholder for en samtale. Derudover, så kan de skrives på forskellige niveauer af granularitet og er nemme at forfine løbende.
Så godt som user stories er tilpasset til vores behov, så er de dog ikke den eneste måde at repræsentere product backlog items på.
De er bare en let tilgang som passer godt ind med core agile principper og vores behov for en effektiv placeholder.
Jeg bruger dem som den centrale placeholder hvortil jeg vil vedhæfte alt andet information, som jeg tænker er relevant og hjælpsomt for at detaljere et krav.
Hvis jeg synes, at user stories er et “forced fit” til en specifik situation (som f.eks. at repræsentere specifikke defekter), så vil en anden tilgang være bedre.
Hvis f.eks. en projektgruppe skriver den følgende user story: “Som kunde vil jeg gerne have, at systemet ikke ødelægger databasen”. Her er det meget tydeligt, at en user story nok ikke er den bedste måde at repræsentere dette problem. I stedet vil en simpel reference til defekten i, f.eks. et system der overvåger defekter, være bedre.
Men hvad er user stories helt præcist? Ron Jeffries, som har skrevet en bog om user stories, har en simpel, men effektiv måde at beskrive user stories på. Han beskriver dem som de tre C’er: card, conversation og confirmation.
Card
Ideen med kortet er rimeligt simpel. Her er ideen, at personer skriver user stories direkte på sticky notes. En typisk skabelon format for at skrive user stories er, at specificere en class of user (brugerrollen), hvad den class of users gerne vil opnå (målet) og hvorfor disse brugere gerne vil opnå det mål (fordelene).
User Story Skabelon Eksempel:
Som en <Brugerrollen> vil jeg gerne <målet>, fordi <fordelene).
Det er ikke meningen med kortet, at det skal fange alt den information som skaber kravet.
Faktisk, så bruger man med vilje små stykker papir for, at begrænse pladsen og dermed fremtvinge korthed.
Et kort bør have et par sætninger, som fanger essensen eller meningen af et krav. Det virker som en placeholder for meget mere detaljeret diskussioner som vil finde sted mellem interessenter, produktets product owner og udviklingsholdet.
Conversation
Detaljerne af et krav er vist og kommunikeret i en samtale mellem udviklingsholdet, product owner kunden, og andre interessenter. En user story er bare et løfte om at holde den samtale.
Her skriver jeg “den samtale”, men i virkeligheden er samtalen ikke bare noget der sker en gang, men mere en on-going dialog.
Der kan være den første samtale, når user storyen er skrevet, en til samtale når den er forfinet, en til når den er estimeret, en mere under sprint planning og til sidst on-going samtaler, når denne user story bliver designet, bygget og testet under en sprint.
En af fordelene ved user stories er, at de skifter noget af fokus væk fra at skrive og hen mod samtaler. Disse samtaler tillader en rigere form for vidensdeling og samarbejde, som forsikre at de korrekte krav gives udtryk for og at de er forstået af alle.
Selvom samtaler primært er verbale, så kan de også suppleres med dokumenter. Samtaler kan måske føre til en UI skitse, eller en uddybelse af forretningsregler som skrives ned.
Vi smider altså ikke alle dokumenter ud for udelukkende at bruge user stories og deres tildelte story cards. User stories er blot et godt startpunkt for at komme frem til essensen af det der er ønsket og for at give en påmindelse om at diskutere krav mere detaljeret, når det er nødvendigt.
User stories kan og bør dog også suppleres med alle andre skrevne informationer, som kan hjælpe med at klargøre det der er ønsket.
Confirmation
En user story indeholder også confirmation information i form af “conditions of satisfaction” eller også tit beskrevet som “Accept criteria”.
Disse er godkendelseskriterier som uddyber den ønsket adfærd. De er brugt af udviklingsholdet for bedre at forstå, hvad de skal bygge og teste, og af produktets product owner for at bekræfte, at den user story er blevet implementeret tilfredsstillende.
Hvis f.eks. forsiden af papiret har en par linjer der beskriver denne user story, så kan bagsiden af papiret bruges til at specificere conditions of satisfaction.
Disse conditions of satisfaction kan udtrykkes som godkendelsestests af højt niveau. Disse tests vil dog ikke være de eneste tests, som udføres når denne user story udvikles.
Faktisk, så vil udviklingsholdet have mange flere tests, end den håndfuld der er forbundet med en user story, som vil være på et teknisk detaljeret niveau, som produktets product owner slet ikke kender til.
Godkendelsestesten der er forbundet med en user story eksisterer af flere forskellige grunde. Først og fremmest, så er de en vigtig måde at fange og kommunikere, fra et product owner perspektiv, hvordan vi kan vurdere om en user story er blevet implementeret korrekt.
Disse tests kan også være en hjælpsom måde til at skabe user stories i første omgang og derefter forfine dem i takt med at man lærer mere om nye detaljer. Denne tilgang er ofte kaldet for “specification by example” eller “acceptance-test-driven development” (ATTD).
Ideen er rimeligt intuitiv. Diskussioner omkring user stories kan, og typisk gør, fokusere på at definere specifikke eksempler eller ønsket adfærd.
Detaljegrad
User stories er et godt redskab til at bære items af kunde- eller bruger værdi gennem det Scrum værdiskabende flow. Hvis vi dog kun har en story størrelse (den størrelse, som vil passe ind i en kort-periode sprint), så vil det være svært at lave et højt niveau af planlægning og at få fordelene ved progressiv forfining.
Mindre stories der bruges på sprint-niveau er få små og for mange til at støtte højere-niveau produkt- og release-planlægning.
På disse niveauer har vi behov for færre, mindre detaljeret og mere abstrakte items. Ellers, så vil vi ende i en gryde af mange irrelevante detaljer.
Forestil dig at have 500 meget små user stories og blive spurgt om at levere en leder-niveau beskrivelse af det foreslået produkt for at sikre din funding.
Eller at skulle forsøge på at prioritere mellem alle disse 500 meget små items for at definere næste release.
Derudover, hvis der kun er en (lille) størrelse af user story, så vil vi være tvunget til at definere alle krav på et meget specifikt niveau af detaljer lang tid før vi burde. Ved kun at have små stories udelukker man fordelene ved at progressivt forfine krav på en just-enough, just-in-time basis.
Heldigvis, så kan user stories skrives for at fange kunde- og bruger-værdi på mange forskellige niveauer af abstraktion.
Den største type af stories er dem, som tager et par eller mange måneder i størrelse og kan sprede sig over en hel release eller flere releases.
Mange refererer til denne type af stories som epics, taget fra ideen om at de er stories på størrelse med f.eks. Ringenes Herre bøgerne. Epics er hjælpsomme, fordi de giver et meget big-picture, højt-niveau overblik, over hvad der er ønsket.
Vi vil aldrig flytte en epic ind i en sprint for udvikling, da den er alt for stor og ikke specielt detaljeret. I stedet, så er epics en god placeholder for en stor samling af mere detaljeret stories, som skal laves på et passende tidspunkt i fremtiden.
Den mindste form af user stories er dem, som vi typisk bare referer til som user stories. For at undgå nogen form for forvirring med epics, user stories, eller andre store items, som også er “stories”, så kalder nogen folk disse user stories for enten sprintable stories eller implementable stories, for at indikere, at de er i størrelsen af dage og derfor små nok til at passe ind i en sprint og blive implementeret.
Nogle projektgrupper bruger også termet theme til at referere til en samling af relateret stories. Themes giver en praktisk måde at fortælle, at en gruppe af stories har noget til fælles, som f.eks. at være i det samme funktionelle område.
Jeg tænker typisk på et theme, som en opsummering for en gruppe af noter/stories, som er hæftet sammen for at indikere, at de er ens til hinanden i et område, som vi har vurderet som værende vigtigt.
Tasks er niveauet under stories, som typisk kun er arbejdet på af en person eller måske et par personer. Tasks kræver typisk kun timer for at blive færdige. Når vi går til opgave-niveauet, så specificerer vi hvordan man skal bygge noget i stedet for hvad der skal bygges, som er repræsenteret af epics, features og stories. Tasks er ikke stories, så vi bør undgå, at inkludere opgave-niveau detaljer, når vi skriver stories.
Det er vigtigt at huske på, at termer som epic, feature, story and theme bare er praktiske navne og de er ofte ikke universalt delt. Det betyder ikke rigtigt noget, hvilke navne du bruger, så længe at du bruger dem på kontinuerlig basis, og de andre i projektet er med på hvad du mener.
Det der betyder noget er, at anerkende, at stories kan eksistere på flere forskellige niveauer i projektet og at gøre det vil støtte vores arbejde med at planlægge flere niveauer og at forfine store items om til små items over tid.
INVEST i gode stories
Hvordan ved vi om de stories vi har skrevet er gode stories?
Bill Wake har udviklet seks kriterier med akronymet INVEST, som har vist sig at være meget brugbare når man skal evaluere om stories passer til deres tilsigtet brug eller om de kræver ekstra arbejde.
INVEST kriterierne er Independent, Negotiable, Valuable, Estimatable, Small og Testable.
Når vi kombinerer informationen der stammer fra at bruge hvert kriterie, så får vi et klart billede af hvilke, hvis overhovedet nogen, yderligere ændringer vi måske vil ændre om til at være en story. Jeg vil nu uddybe hvert kriterie.
Independent
Til den grad, som det er praktisk, bør user stories være independent (uafhængige) eller i det mindste kun meget løst relateret til hinanden.
Stories som har en høj grad af afhængighed gør ting som estimater, prioriteringer og planlægning meget mere kompliceret.
For at arbejde på en story, som har mange afhængigheder, så skal alle disse afhængigheder først laves.
Sker det kun i et tilfælde, så er det ikke nødvendigvis så slemt. Men hvis nu man pludselig står med mange stories, som har en høj grad af afhængighed, så kan det hele pludseligt blive meget kompliceret.
Det kan blive meget indviklet at finde ud af hvordan de forskellige stories skal prioriteres og hvilke man skal gå i gang med til næste sprint.
Når man bruger dette Independent kriterie, så er målet ikke at fjerne alle afhængigheder, men i stedet at skrive user stories på en måde, som minimerer afhængigheder.
Negotiable
Detaljerne af stories bør også være negotiable. Stories er ikke en skreven kontrakt i form af et up-front kravdokument. I stedet, så er stories placeholders for de samtaler, hvor detaljerne skal forhandles.
Gode stories fanger meget klart essensen af hvilken forretnings-funktionalitet der er ønsket og hvorfor den er ønsket. Men de efterlader plads til at product owner, interessenterne og projektgruppen kan forhandle alle de små detaljer.
Denne forhandling hjælper alle der er involveret med at undgå en os-mod-dem, fingerpegende mentalitet, som ofte finder sted med detaljeret up-front krav dokumenter.
Når stories er til forhandling, så kan udviklerne ikke sige “Hey, det skulle du have sat ind i dokumentet til at starte med,” fordi detaljerne skal forhandles med udviklerne.
Og forretningsfolkene kan ikke sige “Hey, du forstod tydeligvis ikke kravene i dokumentet, fordi du har bygget den forkerte ting,” da forretningsfolket vil være i hyppig dialog med udviklerne for at sikre, at der er en delt forståelse.
Det at skrive stories, som er til forhandling gør. at man undgår problemerne med up-front detaljeret krav ved at gøre det klart, at en dialog er nødvendig.
Et typisk eksempel på hvor ideen bag forhandling ikke udføres korrekt er, når en product owner fortæller projektgruppen hvordan de skal implementere en story.
Stories skal være omkring hvad og hvorfor, ikke hvordan. Når hvordan ikke er til forhandling, så eliminerer man mulighederne for, at projektgruppen kan være innovativ. Dette innovative spild kan have store økonomiske konsekvenser.
Der er dog tider, hvor “hvordan” noget er bygget faktisk er vigtigt for en product owner. For eksempel, så er der muligvis en regulativ obligation til at udvikle en feature på en bestemt måde, eller der kan være en begrænsning i virksomheden, som gør at brugen af specifik teknologi ikke er muligt.
I sådan et tilfælde vil de stories være en smule mindre til forhandling, da en del af aspektet af “hvordan” er påkrævet. Det er OK; ikke alle stories er til fuld forhandling, men de fleste bør være det.
Valuable
Stories skal være valuable (værdifulde) til en kunde, bruger eller begge. Kunder vælger og betaler for produktet. Brugere bruger rent faktisk produktet.
Hvis en story ikke er værdifuld til dem, så skal den ikke være i en product backlog. Forestil dig at sige “Story #11 er ikke værdifuld for nogen, men lad os stadig bygge den.” Det vil man naturligvis ikke gøre.
Man vil enten omskrive denne story, så den bliver værdifuld for kunden eller brugeren, eller man vil bare fjerne den.
Men hvad med stories, som er værdifulde for udviklerne, men ikke af tydelig værdi til kunderne eller brugerne? Det er OK, at have tekniske stories.
Det fundamentale problem med tekniske stories er, at en product owner muligvis ikke kan se nogen form for værdi i dem, hvilket gør det svært, hvis ikke umuligt at prioritere dem over stories, som giver værdi til forretningen.
For at en teknisk story kan eksistere, så skal en product owner forstå hvorfor han/hun betaler for den og dermed hvilken værdi den i sidste ende vil levere.
Forestil dig, at udviklerne vurdere, at det vil blive nødvendigt at migrere om til en ny version af en type database.
Til at starte med kan en product owner muligvis ikke forstå hvorfor det er værdifuldt at ændre database. Men, hvis projektgruppen får forklaret risiciene ved at fortsætte med at udvikle på en outdated version af en database, så kan det være, at den gældende product owner vurderer, at det er værdifuldt nok at forsinke udførelsen af nye features indtil, at man har fået flyttet alt over i den nye database.
Ved at forstå værdien kan en product owner behandle denne tekniske story, som en hvilken som helst anden værdifuld story, og dermed foretage informeret trade-offs. Som resultat kan denne tekniske story muligvis godt blive en del af produktets product backlog.
I praksis, så bør de fleste tekniske stories dog ikke være inkluderet i et product backlog.
I stedet, så bør denne type af stories være opgaver, som er en del af at få værdifulde stories færdiggjort. Hvis udviklingsgruppen har en meget tydelig definition of done, så bør det ikke være nødvendigt at skrive stories som disse, da det arbejde bare er en del af deres definition of done.
Den primære pointe med dette valuable kriterie er, at alle stories i et backlog skal være værdifulde fra en product owners perspektiv, som repræsenterer kundens og brugerens perspektiv. Ikke alle stories er uafhængige og ikke alle stories er til 100% forhandling, men de skal allesammen være værdifulde.
Estimatable
Stories bør være estimatable af projektgruppen, som skal designe, bygge og teste dem. Estimater giver en indikation af størrelsen og dermed indsatsen og udgiften ved disse stories (store stories kræver en større indsats og koster dermed flere penge at udvikle end mindre stories.)
Det at kende størrelsen på en story giver information, som Scrum projektgruppen kan handle på. En product owner, for eksempel, har behov for at vide prisen af en story for at vurdere dens endelige prioritet i et product backlog. En Scrum projektgruppe på den anden side, kan vurdere ud fra størrelsen af en story om yderligere forfining eller adskillelse er krævet.
En stor story, som vi har planer om at arbejde på snart, skal brydes ned til et sæt af flere mindre stories.
Hvis projektgruppen ikke kan finde frem til størrelsen på en story, så er storyen enten for stor eller for bred til at finde frem til en størrelse, eller projektgruppen har ikke nok viden til at estimere en størrelse.
Hvis den er for stor, så skal projektgruppen arbejde sammen med deres product owner for at bryde den ned til mere håndterbare stories. Hvis projektgruppen mangler viden, så vil nogle former for udforskende aktivitet være nødvendig for at skaffe denne viden.
Small (Passende størrelse)
Stories skal være af passende størrelse, når vi skal arbejde på dem. Stories, som skal arbejdes på i sprints bør være små.
Hvis vi laver en sprint, som er flere uger lang, så vil vi arbejde på flere stories, som hver er et par dage i størrelse. Hvis vi har en to-ugers sprint, så vil vi ikke arbejde på en story der er to uger i størrelse, da risikoen for ikke at færdiggøre den simpelthen er for stor.
Ultimativt har vi altså brug for små stories, men bare fordi en story er stor betyder det ikke, at den er dårlig.
Tænk f.eks. på, hvis vi har en story i størrelsen epic, som vi ikke har planer om at arbejde på i et helt år. Man kan faktisk sige, at denne story er i passende størrelse til når vi skal arbejde på den.
Det skyldes, at hvis vi bruger tid på at bryde denne epic story om til en samling af mindre stories, så kunne det sagtens være spild af tid.
Har vi dog en epic, som vi vil arbejde på i næste sprint, så er den ikke af passende størrelse og vi skal arbejde mere med den for, at bringe den ned i størrelse. Du skal altså overveje hvornår en story skal arbejdes på, når du bruger dette kriterie.
Testable
Stories bør også være testable på en binær måde – de skal enten godkendes af eller fejle deres tilhørende tests.
Det at være testable betyder, at den skal have gode godkendelseskriterier (relateret til forholdene af tilfredsstillelse) forbundet med den story, som er “confirmation” aspektet af en user story, som jeg skrev om tidligere.
Uden kriterier der er testable, hvordan ville vi så vide om en story er done i slutningen af en sprint? Derudover, fordi disse tests ofte giver vigtige story detaljer, så er de måske nødvendige for, at projektgruppen overhovedet kan estimere denne story.
Det er måske ikke altid nødvendigt eller muligt, at teste en story. For eksempel, så har epic-stories sikkert ikke tests associeret med dem, og vi behøver dem heller ikke (vi bygger jo ikke direkte epics).
Det kan også være, at en product owner vurderer en story som værdifuld, men ikke har nogen praktisk måde at måle den på. Denne type stories er ofte ikke funktionelle krav, såsom “Som en bruger vil jeg gerne have, at systemet har en 99,99% uptime.”
Selvom godkendelseskriteriet er meget klar, så er der måske ikke noget sæt af tests, som kan køre i mens systemet er under produktion, som kan bevise at dette niveau af uptime opnås, men kravet er stadig meget vigtigt, da det vil styre designet.
Nonfunctional Requirements
Nonfunctional requirements (ikke funktionelle krav) er en måde, som man ofte ender med at skrive user stories på, men det er ikke noget projektgruppen skal, specielt hvis det virker akavet eller mere praktisk, at skrive dem om til et nyt format.
Som system-niveau begrænsninger, er ikke funktionelle krav vigtigt, fordi de påvirker designet og testningen af de fleste eller alle stories i et product backlog. For eksempel, så er “Web Browser Support” noget der er et krav ved ethvert hjemmeside projekt. Når projektgruppen udvikler hjemmesidens features, så skal gruppen sikre, at hjemmesidens features virker til alle de valgte browsers.
Projektgruppen skal også vælge hvornår disse browsers skal testes. Hvert ikke-funktionelt krav er et primært mål for inklusion i projektgruppens definition of done. Hvis projektgruppen inkluderer “Web Browser Support” kravet i deres definition of done, så bliver projektgruppen nødt til at teste alle nye features der er tilføjet i sprinten med alle de valgte browsers. Hvis det ikke virker med alle sammen, så er denne story ikke done.
Jeg anbefaler, at projektgrupper forsøger,at inkludere så mange af deres ikke-funktionelle krav i deres definition of done som muligt. At vente med at teste ikke-funktionelle krav til sent i udviklingsindsatsen fjerner muligheden for at få hurtig feedback på kritiske system ydeevne karakteristikker.
Analyse Stories
Nogle gange er vi nødt til at lave en product backlog item, som fokuserer på at indhente viden.
Måske har vi ikke nok brugbar viden omkring produktet eller processen med at bygge produktet for at kunne komme videre. Derfor kan det blive nødvendigt at udforske og hente ny viden. Sådan udforskning er kendt som mange forskellige ting: prototype, proof of concept, eksperiment, studie, spike og så videre. De er alle sammen forskningsaktiviteter, som involverer at købe information.
Det kan ofte være en god ide, at bruge en user story som placeholder for forskningsarbejde.
Hvis f.eks. en projektgruppe vil evaluere to mulige arkitekture for en ny filtreringsmotor. Det foreslås, at lave en prototype af begge arkitekture og så køre hastigheds-, scale og type tests på begge prototyper.
Ud fra disse tests får gruppen en kort memo, som beskriver eksperimenterne, resultaterne og projektgruppens anbefalinger for hvordan man skal fortsætte.
Denne specifikke analyse story ligner en teknisk story og som tidligere forklaret, så skal værdien af en teknisk story forklares og berigtiges over for projektgruppens product owner.
Da product owners tænker i økonomiske termer, så skal der være en økonomisk begrundelse for at gøre denne type prototype arbejde.
Der er garanteret et godt teknisk argument for at lave denne analyse story, fordi projektgruppen typisk er blokeret fra at lave fremskridt indtil denne viden er produceret af denne story. Spørgsmålet for Scrum projektgruppen er, om værdien af den nye viden overstiger prisen for at få den.
Her er hvordan en Scrum projektgruppe kunne besvare sådan et spørgsmål. Først og fremmest skal vi kende til prisen for prototyperne og deres tests. Ingen god product owner vil godkende ubegrænset forskning.
Projektgruppen kan måske ikke besvare specifikke spørgsmål indtil en arkitektonisk beslutning er taget, men projektgruppen skal være i stand til at besvare spørgsmålet om hvor stor en indsats den vil bruge på at købe informationen nødvendig for at tage den arkitektoniske beslutning. Derfor skal projektgruppen give en størrelse på denne prototype story.
Lad os sige, at størrelses estimatet indikerer, at hele projektgruppen bliver nødt til at arbejde på denne story i en hel sprint. Vi ved også hvem der er i projektgruppen og længden af sprinten, så vi ved dermed også hvad det vil koste at indhente denne nye viden. Lad os for eksemplets skyld sige, at det koster 10.000 kroner. Herefter skal vi så finde frem til værdien af at få denne information.
Her er en måde vi kan estimere denne værdi. Forestil dig at vi flipper en mønt. Lander den på plat, så udfører vi arkitektur A; men lander den på krone, så bliver det arkitektur B. Nu skal projektgruppen estimere prisen for at være forkert på den.
Hvis f.eks. mønt-flippet sætter os i gang med at arbejde med arkitektur A og at bygge forretnings features på arkitektur A, og arkitektur A viser sig at være den forkerte tilgang, hvor meget vil det så koste at fjerne alt det der er forkert, samt et genskabe det hele igen på arkitektur B?
For eksemplets skyld siger vi, at projektgruppen estimerer dette til at være 500.000 kroner.
Nu har vi nok information til at lave en fornuftig økonomisk beslutning. Vil vi gerne bruge 10.000 kroner på at købe information, som har en forventet værdi på 250.000 (halvdelen af gangene vi flipper mønten vil vi have ret)?
Naturligvis, det virker som en fornuftig forretningsmæssig beslutning. Nu kan deres product owner retfærdiggøre hvorfor denne story er i produktets backlog.
Som en sidste illustration for at bruge økonomi til at retfærdiggøre analyse stories, så lad os prøve, at ændre på tallene.
Hvad sker der hvis projektgruppens svar til “Hvor meget vil det koste, hvis vi er forkert på den?” er 15.000 kroner. I dette tilfælde vil det være en dårlig ide, at udføre prototype-storyen. Hvorfor bruge 10.000 kroner på at købe informationer, som har en forventet værdi på 7.500 kroner?
Det vil simpelthen være bedre bare at flippe mønten (eller at foretage et uddannet gæt) og hvis vi er galt på den, så bare starte forfra med arbejdet ved brug af den alternative arkitektur.
På grund af nutidens teknologi, så er dette scenarie faktisk ikke sjældent. Det er et meget godt eksempel på hvad mange vil kalde en fail-fast strategi (forsøg på noget hurtigt, få hurtig feedback, og vær hurtig til at inspicere og tilpasse).
Indsamling af stories
Hvordan opstår stories? Traditionelle metoder til at skaffe krav involvere at spørge hvad brugerne vil have. Det er dog ikke den bedste tilgang. Brugere er nemlig meget bedre til at kritisere end de er f.eks. forfattere.
Hvis du spørger en bruger “Hvad vil du have?”, så har hun eller han måske ikke noget svar. Selv hvis personen besvarer dit spørgsmål og vi bygger præcis hvad der er blevet efterspurgt, så kan det være, at der bliver svaret:
“Ja, du gav mig præcis det jeg gerne ville have og nu jeg ser det, så vil jeg gerne have noget andet.”
Vi har højst sandsynligt alle sammen oplevet noget der minder om den episode.
En bedre tilgang er, at involvere brugere, som en del af projektgruppen der skal vælge hvad der skal bygges, og der holdes hele tiden øje med hvad der bygges. For at promovere dette niveau af deltagelse, så vælger mange organisationer at bruge user-story-skrivning workshops med det principielle formål, at generere mindst det første sæt af user stories.
Nogle bruger også story mapping til at organisere og giver bruger-centreret kontekst til deres stories.
User Story-Writing Workshop
Målet med en user-story skrivning er, at kollektivt brainstorme ønsket forretningsværdi og lave user story placeholders til det som produktet eller servicen skal gøre.
En workshop indeholder typisk både projektets product owner, ScrumMaster og udviklingsholdet, i samarbejde med interne og eksterne interessenter. Det fleste workshops tager alt fra få timer til flere dage. De varer sjældent længere end det og det burde de heller ikke.
Målet er ikke at genere et fuld og komplet sæt af user stories up-front (skin til et komplet kravdokument på sekventiel udviklingsprojekt.
I stedet, så har workshoppen typisk et specifikt fokus. For eksempel, hvis man foretager en workshop i forbindelse med release planlægning for, at generere et kandidat sæt af stories til den kommende release.
Hvis det er den første workshop, så starter jeg den typisk ved at udføre user role analyse. Målet er at vurdere samlingen af user roles, som kan blive brugt til at berige the user role delen af vores stories.
Selvfølgelig, så har markedsføring eller markedsresearch folk måske en god definition af vores brugere i andre aktiviteter fra før denne workshop går i gang, som kan bruges.
Under en workshop er der ikke nogen standard måde at genere user stories. Nogle projektgrupper foretrækker, at arbejde top-down, mens andre foretrækker at arbejde bottom-up.
Top-down tilgangen involverer at starte med en stor story (som en epic) og derefter koncentrere indsatsen på at skabe en mere ansvarlig samling af mindre stories, som er associeret med en epic.
Et alternativ er at arbejde mere bottom-up og at starte med det samme med, at brainstorme stories, som er forbundet med den næste release af et eksisterende system. Der er ikke en rigtig eller forkert tilgang; brug hvilken som helst tilgang der virker for dig, eller skift mellem tilgange for at få de største fordele af begge.
Story Mapping
Story Mapping er en teknik, som Jeff Patton har gjort meget populær. Den tager et brugerfokuseret perspektiv for at genere et sæt af user stories. Den basale ide er, at nedbryde high-level brugeraktivitet ned til et workflow, som kan yder nedbrydes ned til et sæt af detaljeret opgaver.
Jeff Patton bruger termer som aktivitet, opgaver og underopgaver for at beskrive hierarkiet i et story map. For at være konsekvent med terminologien jeg har introduceret tidligere, så vil jeg bruge epic, theme og user story.
På det højeste niveau er epics, som repræsenterer store aktiviteter af målbar økonomisk værdi til brugeren.
Vi opdeler disse Epics i themes. Hvert theme er så nedbrudt om til et sæt af implementerbare user stories, som er arrangeret vertikalt i en prioriteret rækkefølge på backloggen (faktisk mere i ønsket rækkefølge, da vi højst sandsynligt ikke har estimeret disse stories endnu og vi ikke kan vide den endelige prioritet før vi kender udgifterne).
Ikke alle stories i et theme behøver at være inkluderet i den samme release.
Story mapping kombinerer koncepterne af brugerfokuseret design med story nedbrydning. Gode story maps viser et flow af aktiviteter fra brugerens perspektiv og giver en kontekst for at forstå individuelle stories og deres forhold til store enheder af kundeværdi.
En forskel mellem traditionel story-writing workshops og story mapping er, at under denne workshop, så er vi primært fokuseret på at genere stories og ikke så fokuseret på at prioritere dem (den vertikale position af implementerbare stories i et story map).
Derfor vil vi måske bruge story mapping som et komplement til workshoppen, som en teknik for at hjælpe os med at visualisere prioriteringen af disse stories. Story maps giver et todimensionel overblik af et product backlog i stedet for en traditionel lineær (en-dimensionel) product backlog repræsentation.
Konklusion
I dette indlæg har jeg diskuteret hvordan kravene er behandlet forskelligt med et Scrum projekt i forhold til et traditionel, sekventielt udviklingsprojekt.
I et projekt, som bruger Scrum skaber vi placeholders for krav kaldet product backlog items. Disse items er ofte beskrevet som user stories og er kørt gennem en Scrum process med et fokus på samtaler og workshops, som en metode til at uddybe på detaljerne af kravene.
Vi bruger også en strategi af løbende forfining af større, mindre detaljeret stories til mindre, mere detaljeret stories på en just-in-time måde,
Derefter har jeg formelt introduceret user stories ved at beskrive dem i konteksten af “card, conversation og confirmation.”
Jeg gik derefter videre til at diskutere hvordan user stories kan bruges til at repræsentere forretningsværdi på flere forskellige niveauer af abstraktion. Derefter forklarede jeg hvordan INVEST kriterierne er hjælpsomme til at vurdere om vi har gode user stories.
Efter det introducerede jeg måder at håndtere ikke-funktionelle krav og analyse aktiviteter.
Jeg konkluderede med en diskussion om hvordan man kan skaffe user stories, fokuseret på user-story-writing workshops og story mapping.
