- 2015/08/06
- Nederlands
Rekenfactoren¶
Geïntegreerd Agile gebruikt, net zo als scrum, een vrij statistische aanpak om te sturen. We kijken naar de prestaties van het team als geheel en houden nooit bij hoe lang een individueel teamlid over een specifieke taak doet. Dit zorgt ervoor daar de medewerker niet gestraft wordt als zij/hij zich inzet voor het algemeen nut.
Updated on 2015/08/06
Updated on 2015/08/06
Op de vernieuwde site, is dit verhaal van Rough naar Narrative verhuisd.
Toch is het belangrijk om zicht te hebben op de prestaties, van het team dus. In veel scrum-teams
gebeurt dit met voor buitenstaanders vage begrippen als “velocity” en “story- of
feature-points”. Omdat het dan (te) moeilijk is om te oordelen of een team hard werkt, of juist de
kantjes er van afloopt, valt men soms weer terug op harde cijfers: mensuren.
Dat heeft echter grote nadelen.
Middels een aantal rekenregels en factoren is het echter mogelijk zowel de voordelen van relatieve
schattingen (in FeaturePoints) en harde cijfers te combineren. Gebruik deze factoren
echter altijd pragmatisch.
Ik ga er altijd vanuit dat het model om de werkelijkheid te voorspellen minder nauwkeurig is dan de
werkelijkheid zelf.
De k-factor¶
De k-factor, vaak een waarde tussen 1.1 en 2.5, kan na afloop van een sprint berekend worden. En varieert weinig tussen twee (aansluitende) sprints. Daarom kan hij bij de volgende sprint gebruikt worden om de inschattingen van het team te corrigeren.
Deze factor omvat allerlei indirecte uren, zoals koffie-pauzes en (project)meetings; maar is nog belangrijker is de schattingsvaardigheid van het team. Zo zijn ontwikkelaars vaak te optimistisch zijn in hun schattingen; de k-factor corrigeert dat. Het idee is dat het makkelijker is dit getal te berekenen en consequent alle schattingen (van taken) met deze factor te vermenigvuldigen, dan ‘beter’ te leren schatten.
Berekenen¶
De k-factor is, wiskundig, de verhouding tussen de werkelijk benodigde (mens) uren en het aantal ingeschatte (T2C) uren:
Dit berekenen kan pas achteraf, dus na de eerste sprint. Tot die tijd gebruik ik een geschatte waarde; vaak 1.5, soms 2.0. Die initielle waarde is een stukje vakmanschap en inschatting van het team.
Het berekenen van bovenstaand sommen is vrij makkelijk.
Zo komt de som van de gemeten (werkelijk) mensuren globaal overeen met de lengte van de sprint (in
dagen), maal de omvang van het team (in mensen), maal het aantal werkuur per dag (typisch
8uur/dag). Dat is veel handiger dan dit bijhouden per taak.
Ook de som van de initieel geschatte uren is eenvoudig: dit is het punt linksboven op de
BurnDown-Chart. Wat we nog moeten corrigeren door te delen met de toen gebruikte
k-factor. Om die reden wordt die k-factor typisch genoteerd in de sprint-administratie
Gebruik¶
In de P2 planningssessie, worden alle taken geschat (met PlanningPoker) in mensuren. En dan direct vermenigvuldigt met de k-factor en dan (afgerond) opgeschreven als T2C uren.
Notitie
De initiële totale T2C-uren moeten globaal overeenkomen met het aantal beschikbare mensuur. Anders klopt de k- en of de v-factor niet; zie verder.
In sommige teams is deze factor echt constant en vaak hoog, terwijl andere teams leren gaandeweg
beter schatten; dan gaat gedurende het project die factor omlaag. In beide gevallen komen er
realistische getallen uit de P2 planning-sessies.
De k-factor wordt dus alleen op sprint niveau gebruikt.
De v-factor¶
De v-factor lijkt conceptueel veel op de k-factor; maar wordt gebruikt op project-niveau. Het geeft
aan hoeveel mensdagen nodig zijn om één FeaturePoint te bouwen. Dit kan achteraf (per
sprint) eenvoudig berekend worden; door deze twee getallen op elkaar te delen.
We normeren dit naar mensdagen (of mensuur), zodat teamomvang en sprintduur geen invloed hebben op
dit getal.
De v-factor geeft als het ware de hoek aan waarmee de BAV grafiek omhoog loopt.
Hij wordt dus niet gebruikt voor de dagelijkse projectsturing; hij is voornamelijk bedoeld om naar
touchdowns en/of productreleases te kijken.
Ook wordt deze factor gebruikt (door de ScrumMaster) om de product-owner te vertellen hoeveel
FeaturePoints hij mag selecteren voor de komende sprint.
Velocity of v-factor?¶
In Geïntegreerd Agile gebruiken we altijd de v-factor. Conceptueel komt deze overeen met de
velocity in (standaard) scrum; beide geven aan hoeveel FeaturePoints het team kan
realiseren per tijdeenheid.
De (scrum) ‘velocity’ is een maat per sprint, en geldt alleen als het team gelijk blijft. Maar de
team-omvang kan groeien of krimpen. Ook kunnen teamleden kunnen op vakantie gaan. En er zijn soms
goede redenen om een sprint een weekje langer of korter te plannen; bijvoorbeeld door vakanties. In
Geïntegreerd Agile willen we daar mee om kunnen gaan; daarom normeren we per mensdag.
Als de teamomvang en de sprintduur constant zijn kunnen we de ‘velocity’ berekenen door het aantal
teamleden, maal het aantal werkdagen in sprint, te vermenigvuldigen met de v-factor.
Maar ook als een (of beide) varieert geeft de v-factor een redelijke voorspelling van hoeveel
FP gerealiseerd kan worden. Daarom vind ik de v-factor handiger dan ‘velocity’.
De J-factor¶
Scrum doet (vaak) alsof iedereen in het team gelijk is; ook qua kennis en vaardigheden. Dat model
is incorrect; zo zijn programmeurs en testers niet volledig uitwisselbaar. Maar aangezien de
verhouding ontwikkelwerk en testwerk min of meer constant is dit in praktijk geen probleem.
Modelmatig is er ook geen verschil tussen seniors en juniors; we schatten op basis van een
gemiddelde. Ook dat werkt prima om de voortgang te bewaken.
Soms levert dit echter een probleem op: het kan voor de junior-medewerkers frustrerend zijn als zij altijd veel langer over een taak doen. Zeker als er een gat zit tussen de ervaren en onervaren mensen. De ene helft loopt altijd uit, de andere helft is altijd eerder klaar!
Dit wordt opgelost met de J-factor. Alle taken worden ‘gewoon’ ingeschat, waarbij de afspraak
is dat een junior een factor-J langer over een taak mag doen dan senior teamleden. Zodra hij een
taak oppakt zal hij de T2C direct omhoog aanpassen. Daarna kan die taak normaal “opgebrand worden”.
Nu zal hij zijn taken typisch kunnen afronden: soms met enige uitloop en soms ietsje eerder; maar
gemiddeld exact op tijd. Dit werkt motiverend.
Ook bij het bepalen van de sprint-capaciteit wordt deze term gebruikt. De beschikbare dagen (of
mensuren) van J-teamleden wordt door deze J-factor gedeeld. Daarmee is het model weer
consequent.
Bij het tekenen van de :term`BurnDown` wordt de J-factor meestal genegeerd. Hoewel dit
rekenkundig niet correct is, is de afwijking klein. Daarnaast geeft die rekenkundige correctie in
de praktijk geen extra stuurinformatie; het is dus handiger om die te negeren.
Als het beeld ontstaat dat J-medewerkers hun taken vaak ‘te snel’ afronden kan achteraf
geconstateerd worden dat ze minder junior worden. En kan de J-factor omlaag.
Alhoewel de J-factor ‘achteraf’ exact berekend kan worden is dat zelden nodig. Een grove
inschatting (en aanpassing) volstaat. Het is primair een middel om te motiveren. Het opheffen van
de factor is vaak beter, want motiverend, dan een kleine correctie.
Reken of sturen?¶
Bedenkt dat, nu u allerlei getallen in andere getallen kunt omrekenen, dat de kracht van Geïntegreerd Agile niet ligt in het cijfermatig aansturen van het team. Het motiveren en faciliteren van het team is veel belangrijker!
Het verschil tussen een gemotiveerd, ambitieus team en een team dat zich weinig aantrekt van een
externe, overoptimistische planning is een nauwelijks te berekenen in een factor. Maar heeft veel
meer invloed dan bovenstaand factoren.
Omgekeerd kan een te cijfermatige benadering er voor zorgen dat u het team in de verkeerde richting
stuurt. U wilt voorkomen dat u zeer betrouwbaar kunt voorspellen dat er nauwelijks voortgang is!
Disqus
Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.