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

Hvad er ikke allerede erklæret død? Testdrevet udvikling 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 snappet overskrift. I den forstand 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. Elementerne øverst i produktets efterslæb er således ikke episke, men små historier. Nede i efterslæbet finder du typisk epos. Over tid "skives" eposerne ind i historier, der kan trækkes ind i en sprint.

Det er hvad jeg har undervist i årevis på mine uddannelseskurser. 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 epics på

Indtil videre har jeg fundet tre måder virksomheder håndterer epics på. Ingen af ​​dem er praktiske. Lad os kalde dem:

Opløsning

1. Opløsning

Links

2. Links

Træer

3. Træer

1. Opløsning

Opløsningsprincippet er enkelt. Et epos er helt opdelt i dets komponenter, de enkelte små historier.

For eksempel kan en episk "Book flight" fra en online flyportal opdeles i de individuelle procestrin. Så "Log ind", "Søg fly" 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 teamet det episke og starter udviklingen til 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 til historierne er mulige under udvikling, kan du ikke definere alle historierne på forhånd.

Scrum Guide siger:

En produktets efterslæb er aldrig komplet. […] Krav holder aldrig op med at ændre sig.

Hvis du skal levere et fast omfang, skal du stoppe med at foregive. Glem epos, og beskriv de detaljerede krav på forhånd. Bare påstå ikke at være agile da.

2. Links

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

Risikoen er, at over tid øges mængden af ​​epics. 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 din efterslæb fra tid til anden. Jeg betragter dette som værdi uden merværdi. 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æ:

Skildring af epics som et træ

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

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 smidig tilgang bør de ikke have høj prioritet.

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

Alternativet til epics

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

Jeg taler om temaer.

Et tema kan betragtes som en yderligere egenskab ved historierne. Normalt deler flere historier det samme tema. Historien "Søg flyvning" kunne have temaet "Bogflyvning". Et uddrag fra bagtægten kunne se sådan ud:

Brugerhistorier med tema

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

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

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

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

Navnene på brugssager bliver senere temaer i efterslæbet. Men hvordan kommer du fra brugssagerne til historierne? Til dette er Story Mapping en god pasform:

De to øverste linjer på eksempelkortet viser brugssagerne "Bogflyvning" og "Administrer profil" og deres grundlæggende strøm. Under de individuelle trin hænger teamet alternativerne: andre processer, fejl og så videre. Disse gule noter kaldes brugeropgaver.

I Backlog Refinement henter teamet historierne fra brugeropgaverne. En opgave kan tjene som historiens titel. Holdet tilføjer detaljer som acceptkriterier til historierne.

Konsekvenserne

Anvendelse af denne alternative tilgang har konsekvenser. For eksempel indeholder produktets efterspørgsel kun historier til de næste 1–2 sprints. Så måske 10-20 historier.

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

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

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

  • Brug sagdiagrammer eller temaer giver det langsigtede perspektiv for styring. I 1 år eller endda længere. Men: de er ikke egnede til at specificere detaljer.
  • Historiekort danner grundlaget for frigørelsesplanlægning. Interessenter, der er interesseret i udgivelsen, opretter historiekortet med teammedlemmer. (På grund af nye fund kan omfanget ændres under udvikling.)
  • 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 produktets efterslæb er dybest set som en indkøbsliste. Vil du skrive ned, hvad du vil købe om et år?

Sidst, men ikke mindst, fremkalder epikernes død forbrugernes død. Hvis du vil have noget, skal du være enig med teamet 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 imidlertid går tabt i dette tilfælde, er det "store billede", som jeg har vist i brugssagsdiagrammet.

I sidste ende bestemmer produktets egnethed for brugerne dets succes. Ikke hvordan det blev lavet. Dette gælder for alle udviklingspraksis, inklusive epics.
Måske har du fundet en fornuftig måde at håndtere epics på? Fortæl mig det derefter i kommentarerne.

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