Man kan skilja på hur precist ett estimat är och hur korrekt det är. Precision beskriver estimatets spännvidd. Korrektheten hur nära estimatet är det faktiska utfallet.
Om jag säger att jag föddes kl 13:37 den 12 augusti, så är den informationen väldigt precis. Om jag å andra sidan säger att min födelsedag är i januari, så är det mindre precist. Det senare är dock mer korrekt, eftersom jag faktiskt föddes i januari.
Om utfallet ligger inom estimatets intervall så kan man säga att det är korrekt.
Det hjälper att förstå skillnaden mellan korrekthet och precision, och att fundera på om ens egna estimat är korrekta, precisa, eller både och. Eller ingetdera.
I den här artikeln går jag igenom:
Varför korrekthet och precision är betydelsefullt
Viktiga skillnader mellan olika typer av estimat
Varför korrekthet och precision är viktigt
Föreställ dig att du är en intressent i ett stort mjukvaruprojekt. Kunderna väntar otåligt på att produkten ska levereras. Du behöver kommunicera någonting, du behöver svar!
Utvecklingsorganisationen känner trycket, och vill hjälpa. Dom tar sig an utmaningen och börjar planera releasen och ta fram siffror. Den intuitiva reaktionen är ofta att analysera i detalj, identifiera allt arbete, och estimera det. Målet är tydligt: en korrekt och precis plan.
En roadmap tas fram, resultat beräknas. Blänkande slides presenteras på stora skärmar i konferensrum. Känns som att dom verkligen gjorde ett gediget jobb den här gången! Säkerligen tillräckligt grundligt för att man ska kunna lite på siffrorna. Det känns... ambitiöst.
Det är nu varningsklockor 🔔 borde ringa och det är dags för några viktiga frågor:
Hur korrekta är dom här estimaten egentligen?
Hur säkra är teamen att dom kan leverera enligt planen?
Saken är den att estimaten inte är vatten värda - oavsett hur precisa - om dom inte är korrekta. Korrekthet trumfar alltid precision! Men mjukvaruutvecklings inneboende komplexitet gör det omöjligt att estimera precist i början av ett projekt. Inte på grund av dåliga uppskattnings- eller analyskunskaper. Helt enkelt för att komplexa system inte går att förutsäga långt i förväg.
Det är omöjligt att tillhandahålla precisa och korrekta estimat tidigt i ett projekt. Inte på grund av brist på uppskattnings- eller analyskunskaper. På grund av mjukvaruutvecklings inneboende komplexitet.
Hög precision - Hög korrekthet
Den ideala situationen: något är både precist och korrekt. Det innebär att du kan vara säker på att estimatet mer eller mindre stämmer, och inte kommer avvika från det givna värdet. Ett exempel på ett hög precision-hög korrekthet estimat skulle kunna vara "Teamet kommer göra färdigt epicen på 53 ideala utvecklardagar."
Hög precision-hög korrekthet estimat är kanon, men försiktighet åberopas. Det är sällsynt att den här typen av estimat är realistiska, och det är mycket troligare att vad du egentligen tittar på är ett estimat av nästa typ.
Hög precision - Låg korrekthet
Många gånger så framställs estimat som hög precision-hög korrekthet, men i själva verket är de hög precision-låg korrekthet. Dom här estimaten är särskilt lömska, då de ger en illusion av trygghet och precision, medan dom i verkligheten är nästan garanterade att missa målet. Inte sällan med mycket!
Hög precision-låg korrekthet estimat karaktäriseras av detaljerat data uttryckt i smala intervaller och precisa storheter (till exempel timmar), men utfallet är hamnar utanför estimatets intervall. Om teamen tillfrågas är dom ofta tydliga med att dom har låg konfidens i den här typen av estimat.
Hög precision-låg korrekthet estimat är toxiska. Dom göder misstro, stress och dålig kvalitet.
Hög precision-låg korrekthet estimat är toxiska. Dom göder misstro, stress och dålig kvalitet.
Sorgligt nog är den här typen av estimat överrepresenterade i mjukvarubranchen. Jag tror att det här beror på flera skäl:
Både ingenjörer och projektledare frossar i detaljer, och överskattar ofta sin förmåga att analysera och planera.
Intressenter gillar exakta siffror eftersom de tror sig veta vad dom kommer få och när. Dom vill tro på detaljerade planer.
Icke-tekniska intressenter saknar förståelse - och viljan att lära sig - hur mjukvaruutveckling fungerar och dess inneboende komplexa natur. (Ett avslöjande tecken är när utvecklingsorganisationer jämförs med "fabriken".)
Men igen, korrekthet trumfar alltid precision, och tricket är att åstadkomma så precisa estimat som möjligt men utan att göra avkall på korrektheten. Det betyder att du ofta måste nöja dig med låg precision-hög korrekthet estimat.
Låg precision - Hög korrekthet
Det här är vanligtvis den typ av estimat du ska sikta på. Låg precision-hög korrekthet estimat karaktäriseras av spännvidder och ändamålsenliga storheter. Ett exempel på ett låg precision-hög korrekthet estimat kan vara "Teamet kommer göra färdigt epicen om 10 arbetsveckor ± 2 veckor".
Låg precision - Låg korrekthet
Ibland är både precision och korrekthet låga, och estimering är i princip meningslöst. Exempelvis om man byter till en ny obeprövad teknologi, eller om kraven är okända eller det finns andra stora risker.
Om detta är fallet så är enda rimliga vägen framåt att nå en position där man kan åstadkomma låg precision-hög korrekthet estimat - innan man kommunicerar något externt.
Gör en tidsbegränsad "tracer bullet" eller "spike".
Påbörja implementationen, och välj avsiktligt saker som gör det möjligt att ta fram mer korrekta estimat och minska risker.
Avslutningsvis
Säkerställ att du förstår vilken typ av estimat du har att göra med, och kommunicera därefter. Se till att mottagarna har rätt sinnestillstånd, och inte blint litar på estimat med låg korrekthet.
Som utvecklingsorganisation:
Kommunicera bara korrekt data.
Tid är troligen relevant i slutändan, men estimera i relativ storlek - och beräkna kalendertid efteråt.
Välj lämpliga storheter som reflekterar estimatens precision. Välj exempelvis veckor och månader istället för timmar.
Som stakeholder:
Utmana estimat som verkar för bra för att vara sanna (läs: för precisa för att vara korrekta).
Tydliggör att du värderar korrekthet mer än precision.
Tvinga inte organisationen att reducera estimaten för att möta affärsbehov. Separera affärsrisker och estimat, och ta ansvar för riskerna du tar.
I nästa blogpost kommer jag prata om hur man kan bryta ner stora projekt och skapa korrekta initiala estimat.
Comments