Estimatie voor mobiele projecten — wat is het, methoden voor het beoordelen van taken

Wat is een estimatie?

Estimatie (van het Engels estimate — schatting) — het voorspellen van de hoeveelheid tijd of moeite die nodig is om een taak uit te voeren. In mobiele ontwikkeling worden estimaties uitgedrukt in uren, dagen, story points of geldelijke equivalenten. Het doel van een estimatie is niet een exacte voorspelling, maar het verminderen van onzekerheid voor het nemen van beslissingen.

Hoe verschilt een estimatie van een verplichting

Estimatie — een voorspelling met een foutmarge. Verplichting (commitment) — een belofte om een taak voor een bepaalde datum uit te voeren. Het verschil is cruciaal: een estimatie zegt „waarschijnlijk 5 dagen„, een verplichting — „we doen het in 5 dagen„. Managers verwarren deze begrippen vaak en veranderen een estimatie in een deadline zonder recht op fouten.

Estimatie als communicatiemiddel

Het proces van estimeren is net zo belangrijk als het resultaat. Wanneer het team de beoordeling van een taak bespreekt, komen verborgen vereisten, afhankelijkheden en risico's aan het licht. Zelfs als het uiteindelijke cijfer onnauwkeurig is, geeft de discussie alle deelnemers inzicht in de taak. Daarom zijn collectieve beoordelingsmethoden (Planning Poker) effectiever dan individuele.

Estimatiemethoden in ontwikkeling

Er bestaan verschillende estimatiemethoden, elk geschikt voor verschillende projectfasen en detailniveaus. De keuze van de methode hangt af van de beschikbare gegevens en de vereiste nauwkeurigheid.

Planning Poker

Planning Poker — de populairste beoordelingsmethode in Agile. Elke ontwikkelaar krijgt een pak kaarten met Fibonacci-getallen (1, 2, 3, 5, 8, 13, 21). Na het bespreken van de taak laten alle teamleden tegelijkertijd hun kaart zien. Als de schattingen verschillen — leggen de ontwikkelaars met de laagste en hoogste schatting hun logica uit, waarna er opnieuw wordt gestemd. De methode elimineert de invloed van autoriteiten en geeft een nauwkeurigere schatting.

T-Shirt sizing

T-Shirt sizing — een ruwe schatting op basis van T-shirtmaat: XS, S, M, L, XL, XXL. De methode wordt gebruikt voor snelle schatting van grote taken (epics) in vroege stadia, wanneer details nog niet bekend zijn. Later wordt elke dergelijke taak gedecomponeerd en geschat in Planning Poker. T-Shirt sizing duurt 5-10 minuten per taak, maar geeft alleen een grootteorde.

Three-point estimation (PERT)

PERT gebruikt drie schattingen: optimistisch (O), pessimistisch (P) en meest waarschijnlijk (M). De uiteindelijke schatting wordt berekend met de formule: (O + 4M + P) / 6. De methode houdt rekening met onzekerheid en geeft een realistischer resultaat dan een enkele schatting. PERT is vooral nuttig voor taken met hoge risico's of nieuwe technologieën.

Nauwkeurigheid van estimatie: verwachtingen vs realiteit

De nauwkeurigheid van een estimatie hangt af van de projectfase en de hoeveelheid bekende informatie. Hoe eerder een schatting wordt gemaakt, hoe groter de foutmarge — dit is normaal en moet worden meegenomen in de planning.

Onzekerheidskegel

De onzekerheidskegel (Cone of Uncertainty) — een model dat beschrijft hoe de foutmarge van een schatting afneemt naarmate het project vordert. In de conceptfase bedraagt de foutmarge 400% (een taak kan 1 tot 4 maanden duren). Op het moment van de sprint — 20% (1-1.2 maand). Bewustzijn van dit model helpt om in vroege stadia geen exacte schattingen te eisen.

Factoren die de nauwkeurigheid beïnvloeden

• Complexiteit van de taak — nieuwe technologie of bekend? Onbekendheid vergroot de foutmarge 2-3 keer.
• Omvang van de taak — kleine taken (tot 2 dagen) worden nauwkeuriger geschat dan grote. Decompositie verbetert de nauwkeurigheid.
• Ervaring van het team — een team dat 6+ maanden samenwerkt, schat 30-50% nauwkeuriger dan een nieuw team.
• Historische gegevens — de aanwezigheid van velocity- en cyclometriemetrics verhoogt de nauwkeurigheid van voorspellingen.

Relatieve vs absolute schatting

Relatieve schatting (in story points) is nauwkeuriger dan absolute schatting (in uren), omdat mensen taken beter kunnen vergelijken dan tijd kunnen schatten. „Deze taak is twee keer zo complex als die„ — een betrouwbaarder oordeel dan „deze taak duurt 8 uur„. Relatieve schattingen zijn niet afhankelijk van de specifieke ontwikkelaar en behouden hun nauwkeurigheid bij wisseling van uitvoerder.

Hoe de nauwkeurigheid van schattingen te verbeteren: beste praktijken

De nauwkeurigheid van estimaties kan worden verbeterd door een systematische aanpak, collectieve discussie en analyse van fouten uit het verleden. Er zijn verschillende bewezen praktijken.

Decompositie tot 1-2 dagen

Elke taak die op meer dan 2 dagen wordt geschat, moet worden gedecomponeerd in subtaken. Principe: als een taak niet met 50% nauwkeurigheid kan worden geschat, is deze te groot. Verdeel het in stappen die begrijpelijk en schatbaar zijn. Na decompositie blijkt de totale schatting vaak 1.5-2 keer groter dan de oorspronkelijke.

Historische gegevens en metrics

Houd een geschiedenis van schattingen bij en vergelijk deze met de werkelijke kosten. Bijvoorbeeld: „taken geschat op 3 story points duren gemiddeld 4 dagen, niet 2„. Gebruik de velocity van het team voor voorspellingen: als het team 20 story points per sprint afrondt, plan dan geen 30. Analyse van de nauwkeurigheid van eerdere schattingen is de beste training voor de schattingsvaardigheid.

Verankering en kalibratie

Verankering — een psychologisch effect waarbij de eerste uitgesproken schatting alle deelnemers beïnvloedt. Om verankering te voorkomen, laten in Planning Poker alle teamleden tegelijkertijd hun kaarten zien, niet om de beurt. Kalibratie — regelmatige vergelijking van schattingen met de werkelijkheid: na 10-20 sprints leert het team nauwkeuriger te schatten dankzij feedback.

Risico's meenemen in de schatting

Elke taak bevat verborgen risico's: ziekte van een ontwikkelaar, probleem met API, wijziging van vereisten. Voeg een risicogecorrigeerde factor toe aan de schatting: voor taken met hoge risico's — een vermenigvuldiger van 1.5-2, met lage risico's — 1.1-1.2. Laat de klant transparant zien welke risico's zijn meegenomen en hoe deze de termijnen beïnvloeden.

Veelvoorkomende fouten bij estimatie

Fouten bij estimatie komen in de meeste teams voor, ongeacht hun volwassenheid. Kennis van deze fouten is de eerste stap naar verbetering.

Optimistische schatting

De meest voorkomende fout — schatting op basis van het beste scenario: „als alles perfect gaat, doen we het in 3 dagen„. In werkelijkheid gaat niets perfect: bugs, vragen over vereisten, afhankelijke taken. Oplossing: schat op basis van het meest waarschijnlijke scenario, niet het optimistische. Gebruik PERT om rekening te houden met variabiliteit.

Schatting onder druk

Wanneer een manager zegt „het moet voor vrijdag zijn„, past de ontwikkelaar onbewust zijn schatting aan deze deadline aan. Schatting onder druk is altijd te laag en leidt tot termijnoverschrijding. Oplossing: de schatting moet voorafgaan aan de deadline, niet andersom. Eerst schat het team, daarna komen de partijen termijnen overeen.

Verwarring tussen complexiteit en tijd

Complexiteit van een taak (hoeveel denken) en tijd (hoeveel doen) — zijn verschillende metrics. Een taak kan eenvoudig maar tijdrovend zijn (10 schermen coderen). Of complex maar snel (een bug vinden in legacy). In story points wordt meestal de complexiteit geschat en wordt de tijd afgeleid van de velocity van het team.

Negeren van contextwisselingen

Een ontwikkelaar werkt niet 8 uur onafgebroken aan één taak: vergaderingen, code reviews, hulp aan collega's, administratieve taken nemen 30-50% van de werktijd in beslag. Contextwisselingen moeten worden meegenomen in de estimatie: in werkelijkheid schrijft een ontwikkelaar 3-4 uur per dag code.