Titt som tätt får jag frågor från kollegor på Sogeti, kollegor ute hos kund eller från personer ute i vårt avlånga land som på ett eller annat sätt handlar om Scrum och Agile. Jag tänkte jag skulle börja dela med mig av dessa konversationer.
Jag vill också uppmuntra dig att maila mig om du just nu tampas med något problem eller frågeställning i just ditt projekt och önskar input och reflektioner från mitt håll. Jag ska göra mitt bästa för att svara på alla mail som kommer in och kommer att publicera valda frågor och dialoger här på bloggen (eventuellt i förkortad och redigerad form). För att maila mig, leta rätt på mail-ikonen i högerspalten.
Jag börjar på en gång och delar med mig av en fråga från en kollega jag fick i början av veckan 🙂
.
Q: Hur estimera buggrättningar i Scrum?
Hej!
Just nu försöker jag köra mitt första scrum-projekt. Det har då uppstått en del diskussioner i projektet ang estimering och rapportering av tid för bug-rättningar. (—)
Bör man lägga in en task för bug-rättning per User Story, eller bör man ta med tid för bug-rättning i estimatet för utveckling? Om man väljer det senare alternativet så blir ju utvecklingstask inte klara förrän test och rättning är klara.
Finns det någon tum-regel för hur mycket tid man bör estimera för bug-rättning?
Tacksam för goda råd!
Mvh
/######
Svar:
Hej ######,
Angående estimeringar…
Det finns några olika approacher till detta…
- Anpassa Velocity – Anpassa velocity för varje sprint (dvs. antalet Story Points teamet committar till under sprint planeringen) så att det finns utrymme (luft) i sprinten att hantera buggrättningar parallellt med att man levererar funktioner och Story Points. Detta betyder att teamet under Sprint Planeringen bara committar till så många Story Points som man historiskt sett faktiskt klarar av att leverera under Sprinten.
- Skruva ner ”effektiv” arbetstid – Dra ner ”effektiv” arbetstid vid sprintplanering. Dvs. om man räknar med 6 effektiva timmar om dagen, räkna med fem istället. (Egentligen en version av 1:an.)
- Bugg-fix tasks till varje Story – Lägg till en task ”Buggfixning” med ett estimat (i timmar) för varje User Story. Ibland tar det längre tid, ibland blir det färre buggar rapporterade. Förhoppningsvis lär sig dock teamet justera storleken på dessa bugg-tasks allt bättre för varje sprint som går.
- Bugg-fix bucket Story – Lägg till en Story (Generell Buggfixning) till vilken man sätter en buffert med timmar att räkna av ifrån när man fixar buggar. När denna hink med timmar är slut lägger man bugg till produktbackloggen eller tar en diskussion med produktägaren om hurvida någon annan User Story ska senareläggas till förmån för buggfixning.
Vilken approach man väljer är egentligen upp till teamet. Välj den taktik som får arbetet och planering att flyta smidigast och som möjliggör snabbast hantering av buggfixning och som hjälper teamet leverera färdig, värdefull och testad mjukvara varje sprint.
Jag tycker inte att man ska betrakta en User Story som färdig förrän den är färdigkodad och färdigtestad i sprinten. Dvs svar ja: en User Story uppfyller inte DONE förrän den är kodad och testad.
Väntar man med testning och buggrättning till sprinten efter så har man naggat rejält i kanten på sin agilitet, introducerat risker och förlängt feedback-looparna samt försämrat insikten i vilken progress projektet faktiskt gör.
Angående rapportering…
Finns det externa krav på teamet (för att t.ex. kunna sortera isär arbetade timmar till olika budgetar) behöver man kanske rapportera och följa upp hur mycket tid som lagts på buggfixning och kanske till och med hur mycket buggfixning det blev för respektive User Story. Generellt finner jag dock inget värde i att logga arbetad tid på sådan detaljnivå då det oftast är svårt att omsätta denna typ av historik till användbar kunskap inför nästa planering. Men självklart, om det faktiskt hjälper teamet att göra bättre och träffsäkrare planering med sådan typ av historisk data – då ska man självklart göra det.
Att redovisa buggfixningstiden (för de User Stories man jobbar i pågående sprint) separat tycker jag är en väldigt dålig idé. Att utveckla betyder att man kodar, testar, fixar, tänker om, planerar nästa steg, kodar, testar, fixar, osv. tills det är klart. Det är så utveckling fungerar. Att fixa buggar på det man håller på med för stunden är en naturlig del av utveckling. Redovisas det separat riskerar man trilla i fällen att uppfinna sub-optimala lösningar för att parera detta. Alla sub-optimala lösningar saboterar alltid helheten.
Bugg-fixningstid som spenderas på features och funktioner som redan levererats tycker jag dock bör loggas separat. Denna tid är att betrakta som Waste då det faktiskt är olyckligt merarbete som beror på att man inte haft en tillräckligt bra teststrategi tidigare sprintar. Teamet ska dessutom hållas ansvariga för att ständigt förbättra sin testprocess och teststrategi så att kvalitén varje sprint blir högre och allt mindre tid behövs spenderas på att städa upp gamla misstag.
Mvh
/Jimmy
Jimmy Janlén "Den Scrummande Konsulten" 