Nincs partial credit

Fontos, de fájdalmas kérdés: mi legyen a sprint végén a “majdnem” kész feladatokkal? Valójában ez két kérdés: automatikusan bekerüljön-e a következő sprint backlogjába, és hogyan könyveljük a pontokat?

Az első kérdés egyszerűbb. Ami nincs kész, az visszamegy a product backlogba. Fontos kimondani, hogy – bár a valóságban az esetek 98% százalékában (mérnöki has alapján végzett becslés, nem hivatalos adat) valóban a következő sprintbe kerül majd – nem kerül át automatikusan a következő sprintbe. Ennek pedig az az oka, hogy egy tudatos döntést szeretnénk kicsikarni a Product Ownerből: kell-e még neki ez a backlogelem? Egyáltalán nem biztos. Elképzelhető például, hogy a céges weblapra húsvét alkalmából animált nyuszikat kellett volna rámolni, de sajnos nem lett kész a sprintben. Mivel a következő sprint már húsvét utánra esik, semmi értelme folytatni a feladatot, egyszerűen ki kell dobni.
Életszerűbb – bár szintén fiktív – példa lehet, ha egy agilis konferencia honlapjára a “call for paper” form nem készül el a sprintben, de a következő sprint végére már lejár a jelentkezési időszak. Így kidobjuk a feature-t, és marad az emailes jelentkezési lehetőség.
Ilyen esetben természetesen, a használt verziókezelő, stb. megoldástól függően még az is elképzelhető, hogy a kidobásnak lesz költsége, így a feature befejezése helyett annak kipucolása jelenik majd meg a következő sprintben, mint feladat.

No de mi legyen a pontokkal? A “majdnem kész” backlogelem eredeti becslése mondjuk 13 pont volt, a csapat úgy érzi, hogy még kb. 5 pontnyi van belőle hátra. Mennyit ér akkor a backlogelem abban a sprintben, ahol nem sikerült befejezni?
A cím sejteti a választ: semmit. Nincs részeredmény (“no partial credit”). A majdnem kész az nincs kész. Nem eladható, nem kiadható, tehát nem ér semmit.
Már csak azért sem, mert ahogy fent olvastuk, lehet, hogy soha nem is lesz a termék része.
De van egy másik fontos oka ennek a szabálynak: azért, mert ha betartjuk ezt a szabályt és sűrűn maradnak félbe nagyobb feladatok a sprintben, csúnya lesz a csapat velocity görbéje.

Nézzük meg a lenti két mintagörbét!

chart1.png

chart2.png

Bár a trend alapján mindkét csapat fejlődik, szépen növekszik a velocity-jük, a második ábra határozottan csúnya. A csúnya görbék pedig nagyon hasznosak, mert bántják a szemünket és arra késztetnek, hogy valamin változtassunk.
Bár egy metrikát mindig könnyű kiszépíteni valódi tartalmi változás nélkül, inkább egy másik utat javaslunk. A lépései:

– No partial credit szabály bevezetése. Ami nincs kész, az nullát ér.
– Velocity görbe figyelése. Ha sok a tüske, akkor hiába jó a trend, valami gyanús.
– Derítsük ki, mi az oka, hogy a csapat sűrűn bukik el nagy feladatokat. Néhány lehetőség:

1. Túl nagyok a backlogelemek

2. Sok a külső függőség

3. Rosszul becsül a csapat

4. Rosszul ütemez a csapat

5. Rossz minőségűek a backlogelemek, sok részlet a sprintben derül ki

– Szüntessük meg az okot.