Implementeringshierarkin i olika standarder

Publicerad den 2022-01-09
Patrik Hallén

Efter inledande analyser av olika agila ramverk/standarder kan vi presentera slutsatserna i en sammanfattande analys. De standarder som ligger till grund för analysen är:

Låt oss först jämföra de olika standarderna till nivåer. Inte oväntat finner vi fem nivåer som överensstämmer fint med andra dimensioner.



Några observationer:

Nivåer

  • Nivå 5 är en kort, enkel och avgränsad beskrivning av önskad funktionalitet sett ur en användares perspektiv.
  • Nivå 4 är en samling av stories som är logiskt grupperade för att utföras av ett utvecklingsteam med en periodicitet på 2-3 veckor.
  • Nivå 3 är omfattande leverabel som är anpassad för att kunna släppas med en periodicitet på 2-3 månader.
  • Nivå 2 är en mycket omfattande leverabel som leder till en större förändring där flera värdeströmmar påverkas.
  • Nivå 1 är en samling av epics som driver mot gemensamt mål.

Namnsättning

Det råder står enighet om objekten ”Epic”, ”Capability”, ”Feature” och ”Story”. Det finns några olikheter, men i stort sett stämmer hierarkin av objekt i produkt backlog, i Archimate representerad av ”Deliverable”.

Ett par avvikelser som är värda att kommentera:

  • SAFe har den mest kompletta hierarkin, även om det kan diskuteras om "Program Epic" och "Portfolio Epic" befinner sig på samma nivå. Det står dock klart att dessa grupperar Epics (i SAFe "Solution Epics"). Epic grupperar "Capability" som grupperar "Feature" som i sin tur grupperar "Story".
  • Atlassian har gjort en förenklad hiearki där fokus verkar ligga på att gruppera "Story" i "Epic" och uppåt i "Initiative". Det finns även ett "Theme"-objekt men dess definitionen om " stora fokusområden som spänner tvärs över organisationen" leder snarare till förmågedimensionen, varför vi utelämnar detta objekt här.
  • Scrum har ett starkt fokus på utveckling. All kravinsamling samlas i "Product Backlog" och för att det ska gå att realisera dessa måste allt konkretiseras, först i "Feature" som sedan bryts ner i "Use Case" och "User Story". Det kan diskuteras om Use Case är en gruppering av User Stories, då definitionen snarare delar upp dessa efter perspektiv: "Use Case" beskriver systemets interaktion med användaren, medan "User Story"  beskriver kraven utifrån användarens perspektiv. Det står dock klart att "Use Case" är större i omfattning och kan spänna över flera sprintar, medan en "User Story" endast kan finnas med i en sprint. Därav följer att vi placerar "Use Case" på nivå 4 och "User Story" på nivå 5. Resonemanget stämmer även väl överens med den separata analys som Prime Arch gjort i ämnet: Användarberättelse eller Användningsfall?
  • Microsoft har gjort flera  implementeringar av agila ramverk i sin molnplattform Azure, och för att få ett kompletterande perspektiv har vi valt att studera deras tolkning av CMMI. Mycket påminner om Scrum där fokus ligger på kravnedbrytning, även om de har valt andra ord.
  • ArchiMate har ett enda generellt objekt och överlåter som vanligt till användaren att skapa sin egen hierarki.

Slutsatser

Det finns en väletablerad hierarki i implementeringsdimensionen, även om det finns några olika varianter. 

Hierarkin består av 5 nivåer, från en områdesliknande indelning på nivå 1 till story på nivå 5. Följande hierarki bör användas för att representera leverabler på olika nivåer:

  1. Initiativ
  2. Epic
  3. Capability
  4. Feature
  5. Story

Fin mappning mot Prime Archs implementeringshierarki!

Länkar