Schatting en Planning van Scrum Projecten

Het schatten van de omvang van de Product- en Sprint Backlog en het plannen van Sprints is een belangrijk onderwerp omdat Agile projecten nu eenmaal werken met kortdurende cycli waar weinig ruimte en tijd is voor afwijkingen. Schattingen worden meestal uitgedrukt in story points of tijd of allebei. Schattingen worden gebruikelijk gemaakt op 2 niveaus en eventueel op 2 verschillende momenten. Aanvankelijk een globale schatting voor de user stories in een Product Backlog, uitgedrukt in story points. Per Sprint, tijdens de Sprint Planning Meeting, een detailschatting voor de user stories die deel uitmaken van de Sprint Backlog. In de Sprint Planning Meeting zal de Product Owner elke user story inhoudelijk toelichten aan het ontwikkelteam, waarna het team de story verder uitwerkt in taken en deze taken vervolgens voorziet van een urenschatting.

Story Point Schattingen

Een story point is een abstracte en relatieve eenheid. De waarde daarvan heeft eigenlijk alleen betekenis binnen een specifiek team. Om het begrip hanteerbaar te maken wordt eerst een eenvoudige user story genomen als referentienorm. Andere user stories worden ingeschat als relatief 1x, 2x, 3x etc de hoeveelheid van die norm. Op die manier krijgt elke user story een initiële omvangschatting. Deze schattingen leveren bruikbare informatie op die handig kan zijn om de  Product Owner inzicht te geven in de globale omvang van het project. Ook is dat handig om bijv. een project  te kunnen indelen in evenwichtige releases.

Uren Schattingen

Tijdschattingen worden vooral op gedetaileerder niveau gedaan waarbij een user story is ingedeeld in herkenbare taken waarvoor de hoeveelheid tijd redelijk kan worden ingeschat. Bij tijdschattingen wordt gebruik gemaakt van het begrip “Ideal Days” of “Ideal Hours”. Dat betreft de tijd die idealiter alleen wordt besteed aan het ontwikkelen en opleveren van de software. In dit verband wordt ook de term “Load Factor” gebruikt die de verhouding aangeeft tussen de totaal te besteden tijd en de “Ideal” tijd. Bijv. bij een load factor 2 wordt maar 50% van de uren daadwerkelijk besteed aan ontwikkelen en opleveren van software.
Qua taken uitwerking is het van belang om naast bouw activiteiten, ook andere aspecten te begroten zoals ontwerp, test, en documentatie en hiervoor aparte taken te definieren. Voor testen is het verstandig om test rollen in het team te betrekken en ook deel uit te laten maken van de Sprint Planning Meeting voor het schatten van de testactiviteiten. Met name voor die testactiviteiten die niet door de ontwikkelaars zelf worden uitgevoerd.

Project Snelheid (Velocity)

Het ontwikkelteam commit zich aan de afgesproken user stories die het in een Sprint denkt te kunnen leveren. Dat is gebaseerd op de schattingen die het team heeft gemaakt. Voor een nieuw team in een nieuwe omgeving kan dat echter behoorlijk onbetrouwbaar zijn. Daarom moet eerst de zogenaamde snelheid (velocity) van het team worden vastgesteld. Deze wordt uitgedrukt in de omvang die een team in Sprints met een vaste doorlooptijd kan leveren. De omvang kan weer worden uitgedrukt in story points of ideaal uren. Pas na een aantal iteraties wordt duidelijk hoeveel story points of ideaaluren een team gemiddeld kan leveren per Sprint. Het commitment van het team houdt niet per definitie in dat ook alles wordt gerealiseerd. Met name voor de eerste Sprints zal dat niet altijd het geval zijn.

Sprint Calculatie

Initieel is de project snelheid nog onbekend. Dan kan een aanname worden gedaan dat een gemiddelde werkdag van 8 uur maar 6 ideaal uren heeft. Er gaan dus per werkdag 2 uur per teamlid verloren aan andere zaken zoals vergaderen, lunchen, etc. Dit houdt een load factor in van 1,333. De volgende formules kunnen worden toegepast om Sprints door te rekenen:

Mandagen = Teamomvang * Werkdagen

Team Velocity [ideaal uren] = Mandagen * 8 / Load Factor

Team Velocity [story points] = Team VelocityNorm * WerkdagenActueel / WerkdagenNorm

Werkdagen = Team Velocity [ideaal uren] / (Teamomvang*8/Load Factor)

Voor een Sprint wordt bepaald hoeveel werkdagen er zijn tussen start- en einddatum. Weekenden en eventuele feest- en vakantiedagen worden hiervan normaal gesproken afgetrokken. Voor een sprint met een doorlooptijd van 3 weken hebben we bijv. 15 werkdagen. Stel we hebben een team van 3 ontwikkelaars dan hebben we 3 * 15 = 45 mandagen = 45 * 8 /1,333 =  270 ideaal uren aan capaciteit beschikbaar. De velocity is dus ook 270 ideaal uren per Sprint. We kunnen daarmee de Sprint vullen met user stories, in prioriteitvolgorde van de Product Backlog, totdat de 270 uren zijn gevuld. Stel dat na een aantal Sprints blijkt dat een story point gemiddeld overeenkomt met 6 ideaaluren. Dan hebben we gemiddeld een norm velocity van 270 / 6 =  45 story points per Sprint. Om de norm velocity op nieuwe sprints toe te passen moet deze herberekend worden naar het actueel aantal werkdagen van de Sprints.

Release Planning

Een eventuele release strategie moet zijn vastgesteld: wordt de applicatie ontwikkeld in meerdere releases. Zo ja wat moet een release bevatten en welke releases moeten wanneer worden uitgerold en naar wie? Voor een releaseplanning wordt een keuze gemaakt voor ofwel een Scope-driven of Date-driven uitgangspunt. Bij een scope-driven uitgangspunt wordt afgesproken dat de scope van een release vaststaat, maar de tijd/datum niet. Andersom bij een Date-driven uitgangspunt wordt afgesproken dat de tijd/datum vaststaat maar de scope niet. Klassieke fout is natuurlijk om beiden te willen vastzetten.

This entry was posted in Agile and tagged , , , . Bookmark the permalink.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd.

De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>