“Hoeveel uur kost dit?” is de lastigste vraag in softwareontwikkeling. Een te lage schatting betekent een ontevreden klant of onbetaald werk. Een te hoge schatting maakt een voorstel onnodig duur. Wij schatten daarom met PERT: per taak drie schattingen, en een bandbreedte in plaats van één getal. Story points gebruiken we voor klantprojecten bewust niet.
In dit artikel leest u hoe dat werkt en wat het voor u betekent. Wat die uren uiteindelijk kosten, leest u in ons artikel over wat maatwerk software kost.
Waarom geen story points?
Story points zijn handig voor een team met een doorlopende backlog. Het team schat relatief (“deze story is twee keer zo groot als die andere”) en weet na een paar sprints dankzij de velocity hoeveel punten het per sprint afrondt.
Voor klantprojecten werkt dat minder goed:
Klanten rekenen in euro’s en weken
Een klant wil vooraf weten wat iets kost en wanneer het klaar is, niet hoeveel punten het is.
Velocity heeft historie nodig
Bij een nieuw project of een klein team ontbreekt die data, en de variatie per sprint is groot.
Onzekerheid verdwijnt in het getal
Een 8 kan “een duidelijke klus” zijn of “geen idee, maar het lijkt groot”. Aan het getal ziet u dat niet.
Hoe PERT werkt
PERT (Program Evaluation and Review Technique) werkt met een bandbreedte in plaats van één getal. Per taak maken we drie schattingen:
Optimistisch (O)
Alles loopt perfect.
Realistisch (R)
Het meest waarschijnlijke verloop.
Pessimistisch (P)
Er gaat het nodige mis, maar het is nog wel denkbaar.
De verwachte duur is (O + 4 × R + P) / 6. De onzekerheid is (P − O) / 6.
Een voorbeeld: een koppeling met een externe API
Stel dat we een koppeling met een externe API bouwen. We schatten O = 2 dagen, R = 4 dagen en P = 12 dagen. De verwachte duur is (2 + 16 + 12) / 6 = 5 dagen, met een standaarddeviatie van ongeveer 1,7 dag.
Dat de uitkomst boven de realistische schatting ligt, is precies de bedoeling. Het compenseert onze natuurlijke neiging om te optimistisch te zijn.
Een grote spreiding is een signaal
Is P veel groter dan O, dan weten we nog te weinig. We onderzoeken of splitsen die taak dan eerst, voordat we er een getal aan hangen.
Wat we eromheen doen
PERT is alleen zo goed als de opdeling eronder. Daarom combineren we het met een aantal andere werkwijzen:
- Scope en aannames opschrijven. Wat zit er wel en niet in de schatting? Scopewijzigingen zijn de grootste oorzaak van overschrijding, dus die maken we expliciet.
- Opdelen in taken van maximaal 1 à 2 dagen. Hoe kleiner de taak, hoe kleiner de schattingsfout. Kunnen we een taak niet opsplitsen, dan begrijpen we hem nog niet goed genoeg.
- Korte onderzoekstaken (spikes). Voor onbekende technologie of externe koppelingen plannen we eerst 2 tot 4 uur onderzoek. Daarna schatten we het echte werk.
- Het onzichtbare werk meetellen. Testen, code review, deployment, migraties, documentatie en overleg zijn vaak 30 tot 50% van de totale tijd.
- Vergelijken met eerdere projecten. Het PERT-totaal toetsen we aan vergelijkbaar werk uit het verleden. Wijken ze sterk af, dan zoeken we uit waarom.
- Eigen historie als correctiefactor. We houden per taak bij wat we schatten en wat het werkelijk kostte. Zo zien we onze structurele afwijking en corrigeren we daarvoor.
- Een buffer over het geheel. Geen opslag per taak, maar 10% over het totaal voor onvoorziene zaken.
Wat betekent dit voor u als klant?
- U krijgt een bandbreedte in plaats van een schijnzekerheid, met een duidelijke uitleg van wat de aannames zijn.
- Bij grotere projecten werken we gefaseerd: een klein, goed afgebakend eerste deel, en daarna een nieuwe schatting met meer kennis.
- Wijzigt de scope, dan ziet u direct wat dat betekent voor tijd en kosten, omdat de opdeling en aannames vastliggen.
- Geen getal uit de losse pols. Als we iets nog niet kunnen inschatten, zeggen we dat, en komen we er na onderzoek op terug.
Wilt u zelf een eerste indicatie voor uw project? Onze prijscalculator voor maatwerk software geeft ook een bandbreedte in plaats van één bedrag.
PERT of story points: onze vuistregel voor developers
PERT en story points sluiten elkaar niet uit. Ze lossen verschillende problemen op:
Story points
- Eenheid: relatieve grootte.
- Onzekerheid: verstopt in het getal.
- Tijd afleiden: via velocity, na meerdere sprints.
- Sterk bij: een doorlopende backlog en een vast team.
- Zwak bij: een vaste prijs of deadline, en weinig historie.
PERT
- Eenheid: tijd (uren of dagen).
- Onzekerheid: expliciet in de bandbreedte.
- Tijd afleiden: direct, uit de schatting zelf.
- Sterk bij: een vooraf afgebakend project en een klein team.
- Zwak bij: veel taken, dus veel schatwerk vooraf.
Onze vuistregel: heeft u een stabiel team en een doorlopend product, gebruik dan velocity. Moet u vooraf een prijs of einddatum noemen, of werkt u met weinig mensen en weinig historie, dan is PERT in combinatie met het bijhouden van geschat versus werkelijk praktischer en eerlijker.
Tot slot
Goed schatten is geen exacte wetenschap, maar wel een vak. Door onzekerheid zichtbaar te maken, werk op te delen en van onze eigen cijfers te leren, kunnen we afspraken maken die we ook nakomen.
Benieuwd hoe dat er voor uw project uit zou zien? Neem gerust contact met ons op.
