Epics er døde. Her er hvad vi skal gøre i stedet.

Hvad er ikke allerede erklæret død? Test Driven Development blev begravet for mange år siden. Stadig fortsætter det med at sprede sig. Selvfølgelig er Agile også død. Men selv traditionelle virksomheder kommer i kontakt med Scrum. De døde fortsætter med at leve, men at erklære noget død er altid godt for en sjov overskrift. I den forstand skal du være vidne til, hvordan jeg ødelægger epos som en smidig praksis.

Hvad er epos?

Udtrykket er vagt. Dette har fordele. Epics er mere til kommunikation end specifikation. Uklarheden gør dem alsidige. Men der er risiko for misforståelser. Jeg holder mig til Mike Cohns definition:

Et Scrum-epos er en stor brugerhistorie. (Kilde)

Jeg bruger udtrykket som dette: Et epos er en historie, der er for stor til at blive implementeret i en Scrum sprint. Varerne øverst i Product Backlog er således ikke epos, men små historier. Nede i efterslæbet finder du typisk epos. Over tid bliver eposerne "skåret" i historier, der kan trækkes ind i en sprint.

Det er det, jeg har undervist i årevis i mine kurser. Det ser ud til at være den generelle konsensus. Intuitivt ved første øjekast. Jeg er her for at forklare, hvorfor det ikke er praktisk.

3 upraktiske måder at håndtere epos på

Indtil videre er jeg stødt på tre måder, hvorpå virksomheder håndterer epos. Ingen af ​​dem er praktiske. Lad os kalde dem:

Opløsning

Links

Træer

1. Opløsning

Princippet om opløsning er simpelt. Et epos er helt opdelt i dets komponenter, de enkelte små historier.

For eksempel kan en episk "Book flight" i en online flight portal opdeles i de enkelte procestrin. Så "Log ind", "Søg flyvning" osv. Hvert procestrin bliver en historie. Holdet estimerer historien. Så længe det er for stort, fortsætter holdet med at skære det. Når alle historier er små nok til at passe ind i sprints, sletter holdet det episke og starter udviklingen af ​​historierne.

Det er den underliggende idé om fuldstændighed, der generer mig. Opløsningen antyder, at et emne kan afsluttes med et forudbestemt omfang.

Men hvis ændringer i historierne er mulige under udviklingen, kan du ikke definere alle historierne på forhånd.

Scrum Guide siger:

Et produktforsinkelse er aldrig komplet. [...] Krav holder aldrig op med at ændre sig.

Hvis du er nødt til at levere et fast omfang, skal du stoppe med at foregive. Glem epics, og beskriv de detaljerede krav på forhånd. Bare hævder ikke at være adræt da.

2. Links

Hvis du ikke opløser dine epos helt, er det fornuftigt at bruge links. Eposerne forbliver nede i efterslæbet. Du forbinder nye små historier til de eposer, som de stammer fra.

Risikoen er, at mængden af ​​epos over tid stiger. Efterslæbet bliver oppustet. Det indeholder epos, som du ikke har brug for mere. Interessenten er ikke længere i virksomheden. Eller emnet er ikke længere relevant.

Selvfølgelig kan du rydde op i dit efterslæb fra tid til anden. Jeg betragter dette som ikke-værditilvækket arbejde. Og du kan undgå det, som jeg vil beskrive senere.

3. Træer

En anden måde er skildringen af ​​epos og historier som et træ:

Du grupperer de små historier efter episk. Ikke en dårlig idé. Men hvad du mister er den ordnede liste over efterslæbet. Hvordan bestemmer du implementeringsordren så?

Selvfølgelig kan du bruge et digitalt værktøj, der understøtter begge visninger. Risikoen: du investerer for meget tid og kræfter i værktøjerne. Hvad er synspunkterne? Hvad er attributterne? Hvad er den underliggende datamodel? Interessante spørgsmål. Men i en agil tilgang bør de ikke have høj prioritet.

Sammenfattende er ideen om gruppering god. Men det er tidskrævende at gøre det.

Alternativet til epos

Der har længe været et alternativ. Det er endda nævnt i det samme blogindlæg af Mike Cohn, som jeg linkede ovenfor.

Jeg taler om temaer .

Et tema kan betragtes som en yderligere attribut for historierne. Normalt deler flere historier det samme tema. Historien "Søg flyvning" kunne have temaet "Book flyvning". Et uddrag fra efterslæbet kunne se sådan ud:

Temaer styres ikke som separate efterslæbselementer. Dette eliminerer oprydningsarbejdet, der diskuteres i kapitlet Links. Det er godt.

Men hvad du mister er processen med gradvis forfining fra de store epos til de historier, der kan implementeres i en sprint. Det er slemt.

Heldigvis er der praksis, der gør det muligt at gøre denne forbedring uden for efterslæbet. En måde at identificere temaer på er et use case-diagram:

Det pæne ved sådanne diagrammer er, at de viser det "store billede" på grund af det høje abstraktionsniveau og den grafiske repræsentation. Til det er et efterslæb uegnet.

Brugssagens navne bliver senere temaer i efterslæbet. Men hvordan kommer du fra brugssagerne til historierne? Til dette passer Jeff Pattons Story Mapping godt:

De to øverste linier på eksemplet viser brugssagerne "Book flight" og "Manage profile" og deres grundlæggende flow. Under de enkelte trin hænger teamet op alternativerne: andre processer, fejl og så videre. Disse gule noter kaldes brugeropgaver.

I Backlog Refinement stammer teamet historierne fra brugeropgaverne. En opgave kan tjene som titlen på historien. Holdet tilføjer detaljer som acceptkriterier til historierne.

Konsekvenserne

Anvendelse af denne alternative tilgang har konsekvenser. F.eks. Indeholder produktbackloggen kun historier til de næste 1-2 sprints. Så måske 10–20 historier.

Alle aktiviteter som yderligere prioritering, estimering og udarbejdelse af acceptkriterier finder kun sted med disse historier. Som det 10. agile princip siger:

Enkelhed - kunsten at maksimere mængden af ​​arbejde, der ikke er udført - er afgørende.

Hvis ledelsen ønsker at få indsigt i udviklingen, er dette muligt på tre niveauer:

  • Brug sagsdiagrammer eller temaer giver det langsigtede perspektiv for ledelsen. I 1 år eller endda længere. Men: de er ikke egnede til at specificere detaljer.
  • Historikort udgør grundlaget for frigivelsesplanlægning. Interessenter, der er interesserede i frigivelsen, opretter historikortet med teammedlemmer. (På grund af nye fund kan omfanget ændre sig under udviklingen.)
  • De, der ønsker at have en dyb indsigt og påvirke detaljerne under udviklingen, deltager i Sprint Review og Backlog Refinement .

Kun i lav højde ser vi detaljerne. Og Product Backlog er dybest set som en indkøbsliste. Vil du skrive ned, hvad du vil købe om et år?

Sidst, men ikke mindst, indvarsler epos 'død forbrugerismens døende. Hvis du vil have noget, skal du være enig med holdet og arbejde tæt sammen.

Efter døden

I diskussionen med kolleger påpegede de, at selv efter en opløsning af et epos kan der tilføjes små historier. Det er rigtigt, og for mig er det en acceptabel løsning. Det, der går tabt i dette tilfælde, er imidlertid det "store billede", som jeg har vist i use case-diagrammet.

I sidste ende bestemmer produktets egnethed for brugerne dets succes. Ikke hvordan det blev lavet. Dette gælder for alle udviklingsmetoder, inklusive epos.

Måske er du kommet med en fornuftig måde at håndtere epos på?

Lær hvordan du administrerer din produktbakke effektivt ved at besøge mit online kursus. Denne artikel blev først offentliggjort på HOOD Blog på tysk.