Van Epic naar Task

Epic, Feature, Product Backlog Item, Task. Wat is het precies en wat is daarvan de omvang? Daar geeft deze blog antwoord op, mét voorbeelden.

Van Epic naar Task

De betekenis, omvang en voorbeelden van Epic, Feature, Product Backlog Item en Task:

• Epic

  Een Epic is een hoofdonderwerp of thema dat over meerdere maanden gaat.

  • Internetbankieren app

• Feature

  Een Feature is een functionaliteit van een Epic, waarvoor je waarschijnlijk meerdere Sprints nodig hebt.

  • Inloggen
  • Saldo inzien
  • Geld overmaken

• Product Backlog Item

  Een Product Backlog Item (PBI) is een klantvraag dat klein genoeg is zodat het (klantwaarde toevoegt én) binnen een Sprint kan worden opgeleverd. Zo’n klantvraag kan je formuleren in het format van een User story:

  • Als app-gebruiker wil ik kunnen inloggen zodat ik bij mijn gegevens kan.
  • Als klant wil ik mijn saldo kunnen inzien zodat ik de status daarvan weet.
  • Als gebruiker wil ik geld kunnen overmaken zodat ik mijn rekeningen kan betalen.

Tip: in een volgende blog wordt het verschil tussen een PBI en een User story toegelicht.

• Task

  Een Task is een taak met als timebox een halve werkdag. Lees hieronder waarom en hoe dat precies werkt.

  • Toevoegen knop
  • Aanpassen pagina

Van PBI naar Task opknippen

Hoe krijg je nu een item op de Backlog opgeknipt tot kleinere taken? Door veel taken te benoemen, deze op te knippen, te specificeren en goed te formuleren.

Taken opknippen en specificeren

Het uitgangspunt voor taken is een timebox van een halve werkdag. Is de taak te groot om binnen een halve werkdag af te ronden? Knip het dan op óf misschien is het wel een PBI. Het opknippen kan in deel 1, 2, 3 maar het is nog krachtiger om te specificeren hóe je het opknipt. In plaats van “Bouwen formulier deel 1” en “Bouwen formulier deel 2”, specificeer je de stappen in “Bouwen formulier stap Persoonsgegevens” en “Bouwen formulier stap Product”.

Meer of minder taken

Het helpt enorm om zoveel mogelijk taken te formuleren zodat er een goed beeld is bij het Development Team wat er allemaal komt kijken bij het afronden van een PBI. Zoals hiervoor al is aangegeven: ga taken opknippen en specificeren. Benoem alle taken die nodig zijn voor het behalen van de omschrijving en om aan zowel de D.O.D. als de specifieke acceptatie criteria van deze PBI te voldoen. Ga hier aan de andere kant wel pragmatisch mee om. Als het meer tijd kost om een taak aan te maken dan hem uit te voeren, dan streeft het zijn doel voorbij.

Taken formuleren met werkwoord

Daarbij is het handig om taken te formuleren met een werkwoord zodat duidelijk(er) is wat er mee wordt bereikt. Bijvoorbeeld:

• Design = Maken design tool
• Bouw = Bouwen tool
• Documentatie = Aanmaken of aanpassen documentatie
• Overleg = Afstemmen met stakeholder
• Test = Testen door collega

Burn Down Chart op basis van taken

Als alle taken binnen een halve werkdag zijn af te ronden, zijn deze allemaal ongeveer even groot. Het maakt dan niet uit of iets een half uur of vier uren duurt, want je blijft weg van schatten in uren. Het (relatief!) schatten (op complexiteit) is al gebeurd op PBI-niveau. De enige richtlijn qua omvang is: globaal binnen een halve werkdag. Als je dit toepast, kan je alle taken (in de Sprint Backlog) een 1 geven. Niet 1 uur of 1 story point, maar de factor 1 van 1 taak. Bij TFS kan je hiervoor het venster “Remaining work” gebruiken. Vervolgens zie je op het Board in een oogopslag hoeveel taken er nog open staan én kan je een Burn Down Chart maken op basis van alle taken. Overigens kan dit ook op een flipover.

Een Burn Down Chart voor de taken geeft een goed beeld of je voor of achter loopt in de Sprint, los van de dagelijkse inspect & adapt of het team op weg is naar het Sprint Goal.

Opknippen: van Epic naar Task