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. Geschreven door Paul Overmars, eerder verschenen op zijn persoonlijke blog.

Epic

Een Epic is een groot onderwerp of thema dat meerdere maanden duurt.

Voorbeeld: Internetbankieren app

Feature

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

Voorbeelden:

  • Inloggen
  • Saldo inzien
  • Geld overmaken

Product Backlog Item

Een Product Backlog Item (PBI) is een klantvraag die klein genoeg is om (klantwaarde toe te voegen en) binnen een Sprint te worden opgeleverd. Zo'n klantvraag kan worden geformuleerd in het formaat van een User story.

Voorbeelden:

  • Als app-gebruiker wil ik kunnen inloggen zodat ik toegang krijg tot mijn gegevens.
  • Als klant wil ik mijn saldo kunnen inzien, zodat ik mijn financiële status kan controleren.
  • Als gebruiker wil ik geld kunnen overmaken, zodat ik mijn rekeningen kan betalen.

Task

Een task is een taak die een halve werkdag in beslag neemt. Dit is een timebox. Hieronder wordt uitgelegd waarom en hoe dit werkt.

Voorbeelden:

  • Knop toevoegen
  • Pagina aanpassen

 

epic_task

Van PBI naar taak: taken opknippen en specificeren

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 halve werkdag. Is de taak te groot om binnen een halve werkdag af te ronden? Knip het dan op of bekijk of het wellicht een PBI is. Het opknippen kan in deel 1, 2, 3, maar het is nog krachtiger om te specificeren hoe 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 het Development Team een goed beeld heeft van wat er allemaal komt kijken bij het afronden van een PBI. Ga taken opknippen en specificeren. Benoem alle taken die nodig zijn om aan zowel de Definition of Done (DOD) als de specifieke acceptatiecriteria van deze PBI te voldoen. Wees hier pragmatisch in. Als het meer tijd kost om een taak aan te maken dan om hem uit te voeren, dan schiet het zijn doel voorbij.

Taken formuleren met werkwoord

Daarbij is het handig om taken te formuleren met een werkwoord, zodat duidelijker is wat er bereikt wordt. Bijvoorbeeld:

  • Design: maken van een design tool 
  • Bouw: bouwen van de tool 
  • Documentatie: aanmaken of aanpassen van documentatie
  • Overleg: afstemming met stakeholder(s)
  • Test: testen door collega

Burn Down Chart op basis van taken

Als alle taken binnen een halve werkdag af te ronden zijn, zijn deze allemaal ongeveer even groot. Het maakt dan niet uit of iets een half uur of vier uur duurt, want je blijft weg van schatten in uren. Het schatten op complexiteit is al gebeurd op PBI-niveau. De enige richtlijn qua omvang is: globaal binnen een halve werkdag. Als je dit toepast, kun 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 kun je hiervoor het venster “Remaining work” gebruiken. Vervolgens zie je op het Board in een oogopslag hoeveel taken er nog open staan én kun je een Burn Down Chart maken op basis van alle taken. Dit kan ook op een flipover.

Een Burn Down Chart voor de taken geeft een goed beeld of je voor of achterloopt in de Sprint, los van de dagelijkse inspectie en adaptatie of het team op weg is naar het Sprint Goal.

Meer weten over Paul Overmars? Klik hier om zijn LinkedIn pagina te bekijken.

Reflectie als begin van elke tip

Sinds het begin van de coronamaatregelen ben ik begonnen met reflectie, wat zich tot op heden dubbel en dwars heeft terugbetaald. Reflectie is een belangrijke vaardigheid die vaak wordt verwaarloosd zodra het "te druk" wordt.

Dit gebeurt vaak in Scrum-teams met matig bezochte reviews of gehaaste retrospectives. Na een sprint gaan we snel door naar de volgende, wat een reflectie is van hoe we ons dagelijks leven benaderen: haastig op zoek naar het volgende doel of de snelle oplossing die voor het oprapen ligt.

Reflectie kan echter een schat aan informatie opleveren over waar het schuurt, wat er beter kan en welke dingen we direct kunnen stoppen. In een periode waarbij we meer dan ooit op onszelf zijn aangewezen, is het van cruciaal belang om dit voor onszelf onder de loep te nemen.

Aan de slag met een Scrum werkwijze?

Aan de slag met een Scrum werkwijze?

Kelly vertelt je over onze aanpak.

+31 6 50161496
Maurice Tolhuisen