• 2011/11/01
  • ALbert Mietus
  • Nederlands
  • Rough Geïntegreerd Agile

Backlogs: Product versus Sprint

Er zijn twee soorten backlogs: de ‘Product-BackLog’ (PBL) en de ‘Sprint-BackLog’ (SBL). Deze zijn ‘anders’, maar gerelateerd. Vooral hun scope en doel zijn anders; en moeten niet verward worden.

Beide backlogs bevatten Features; maar alleen in de Sprint-BackLog zijn die opgedeeld in taken. Deze heeft slechts een scope van een sprint.
De scope van de Product-BackLog is het de gehele ontwikkeltijd van de product; minimaal een paar maanden en vaak jaren.

De PBL

De Product-BackLog omvat alle features die nog niet gerealiseerd zijn, maar wel op het eisen- cq wensen-lijstje van de klant (de ProductOwner) staan. Soms bevat het ook de features die al gerealiseerd zijn; maar het is praktischer om deze op een apart (sub)lijstje te zetten.

De ProductOwner mag deze lijst continue veranderen. Bij nieuwe inzichten komen er features bij; of verschuiven ze, als de prioriteit aangepast word. Ook het team mag met voorstellen komen; maar alleen de ProductOwner mag de volgorde bepalen.

Zodra alle (belangrijke) features van de PBL gerealiseerd zijn, is het product af, en het project beëindigd.

De SBL

De Sprint-BackLog bevat de features die in de (huidige) sprint gerealiseerd worden; in wezen in het de top van de (vorige) PBL. Elke feature is opgedeeld in concrete broken werk: een Task. Ook die taken staan op de Sprint-BackLog.
Taken staan dus nooit op de PBL

Na afloop van elke sprint, is de SBL van die sprint niet meer nodig.
Al wordt hij vaak bewaard, voor historische doeleinden.

Een Sprint-BackLog, die eenmaal opgesteld is, wordt niet meer veranderd.

Dat wil zeggen: de features veranderen niet meer. Als tijden de uitvoering blijkt dat er taken (of activiteiten) ontbreken, gesplitst of samengevoegd moeten worden, of een onjuiste T2C hebben, dan wordt dat wel aangepast. Al zal dat vaak “aan het ScrumBoard” gebeuren. Het aanpassen van het SBL-document is niet nodig.

Bijzonderheden

  • Soms bevat de PBL ook andere zaken, zoals TouchDowns; een opeenvolging van een paar sprints, die samen een bijzonder relatie hebben. Zoals een deadline in een klassiek project, of een release.

  • In de praktijk bestaat een PBL vaak uit drie delen.

    • Het bovenste stuk is heel concreet, de features zijn ingeschat (in FPs), en kunnen zo overgezet worden in (toekomstige) SBL’s. Dit zijn vaak ‘eisen’.

    • Het middelste deel is redelijk concreet, maar nog niet ingeschat. Dit zijn vaak ‘wensen’.

    • Het onderste deel is een verzameling van vage ideeën, afgewezen voorstellen en mogelijke toekomstige uitbreidingen. Veel hiervan zal nooit gerealiseerd worden.

Disqus

Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.

comments powered by Disqus