2.4.1 Sprintavslut

Det kan vara svårt att avgöra när en sprint är redo att avslutas, stängas och ibland även överlämnas. Detta avsnitt beskriver när och hur en sprint kan bedömas som avslutad.

Ofta kan flera delar av utvecklingen samt olika funktioner anses vara klara utan att de faktiskt har kvalitetstestats, vilket kan medföra svårförutsägbara kostnader. Definitionen av att “vara klar” kan därmed tolkas olika av olika parter. Därför är det viktigt att ha tydliga kriterier för när en sprint är klar, dvs. vad som behöver göras innan arbetet med nästa sprint kan påbörjas. Det är väsentligt att lösningar alltid stäms av mot beställaren. Följande steg inom sprinten kan hjälpa med att säkerställa detta:

• Uppgifterna är registrerade och implementerade
• Levererat - Uppgifterna är lösta
• Produktchefen anser att leveranserna motsvarar det sprinten ämnade att leverera
• Innehållet i sprinten är väl dokumenterat
• Resultatet/Leveranserna är testade och godkända

I slutet av en sprint anordnas en så kallad ”sprint-review”. Här diskuteras vad som gjorts/inte gjorts under sprinten i förhållande till sprint backlog och hur det i sin tur påverkar nästa sprint. En sprint backlogg är ett dokument som är kopplad till sprintplaneringen som visar vilka framsteg som gjorts under sprinten men också vilka problem som uppkommit och när de ägt rum. Här kan det vara bra att inkludera övriga intressenter och parter som får möjlighet till att påverka planeringen av nästa sprint. Sprintresultaten bör även presente-ras för intressenterna (samtliga bör bli inbjudna), där teamet visar leverablerna i en kort demonstration. Därefter kan det vara bra att göra en ”sprint-retrospective” där hela projektgruppen (scrum master, teamet och produktchefen) samlas och utvärderar sprinten. De utvärderar arbetssätt, verktyg, relationer och samverkan mm. Dessa utvärderingsmöten tenderar att hamna i skymundan, men är oerhört viktiga för att utveckla kvaliteten på framtida sprintar.

Exempel på scenario kring beslut och problemhantering i agila projekt: Det finns 10 mål som är åtaganden inom sprinten som i sin tur har blivit uppdelade i 30 mindre uppgifter som måste avslutas för att uppnå målen. När det är två veckor kvar av sprinten (sprintens totala tid är 3 veckor) är vi klara med 7 mål, men flera fel har identifierats i systemet som gör att sprintens slutresultat inte kommer att vara användbart. Av problemen är det speciellt ett som är kritiskt för systemets funktion, med två s.k. ”skönhetsfel” som innefattar fel färg på en icke synlig detalj och en liten delkomponent som har fel material. Enligt vattenfallsmodellen skulle det vara logiskt att fortsätta arbeta med de resterande tre målen direkt och på så sätt förbise problemen i nuläget för att skjuta dem framför sig. Dock finns en hög risk att projektresultatet påverkas negativt och att projektet drar ut på tiden. Det är ofta beslut likt dessa som gör att många projekt aldrig tycks bli klara, utan de bara drar ut på tiden om och om igen för att i slutet ha överskridit den ursprungliga tidsplanen avsevärt. Inom ramen för en agil projektmetod förespråkas resultat eller delresultat som är 100% klara. Men samtidigt är det inte helt logiskt att stanna hela utvecklingen för två skönhetsfel. Den agila projektmetoden säger också att vi ska ta itu med det mest kritiska först. Här är det projektbeställaren som fattar det slutliga beslutet.