• 2015/08/06
  • ALbert Mietus
  • 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:

\[\text{k-factor} = \frac{\displaystyle{\sum_\text{in sprint}{\textbf{gemeten}\text{ mensuren}}}} {\displaystyle{\sum_\text{in sprint}{\textbf{initieel geschatte}\text{ T2C van alle taken}}}}\]

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.

\[\text{v-factor} = \frac{\sharp\text{mensdagen}} { \sharp\text{FP}}\]

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’.

comments powered by Disqus