Vägra estimera – guesstimera mera

Reading Time: 2 minutes

I lördagens Dagens Nyheter kunde vi läsa om hur experter med avancerade modeller försökt räkna ut det kommande behovet av intensivvårdplatser. En professor i strukturbiologi med team, en professor i epidemiologi med team samt Folkhälsomyndigheten. Två av dessa missar det faktiska utfallet grovt och i social media tjafsar professorerna om semantiken i de rapporter de släppt och som ligger till grund.

Jag förstår tanken med att försöka göra dessa förutsägelser men endast ett av försöken resulterar i ett godtagbart resultat så här med facit i hand. Om man studerar dessa försök så ser man att två av modellerna är baserade på (ur?)historiska data applicerade till komplexa formler och populism hellre än färsk data från ett jämförbart scenario, som FHM gjort. Eller som vi säger inom mjukvaruutveckling: yesterdays weather.

Kan vi nu inse att inte ens professorer kan förutspå framtiden och lägga ner det vi kallar estimering för komplexa eller komplicerade uppgifter?

Gör som 1 740 andra, prenumerera du med.

Managers, förstå att det aldrig kommer hända att ni får veta dagen när teamet blir klara. Teamet, förstå att management behöver ett guesstimat och våga stå för det.

Ett guesstimat bygger på en magkänsla av teamet. Thats it. Vill man ha exaktare än så får man ge teamet tid och frihet att forska i ärendet med skarp data. Den kan uttryckas antingen i T-shirtstorlekar eller som storycount, dvs hur många stories vi tror oss klara av i nästa sprint förutsatt man har historiska data från minst fem tidigare sprintar. Vill man bli exaktare än så kan man leka vidare med Monte Carlometoden som tar snygg hänsyn till historik. Dock, ge dig inte ut på estimeringsis om du är i den komplexa domänen som mjukvaruutveckling oftast är i.

Du måste ta hänsyn till uppgiften som sådan innan du guesstimerar. Om uppgiften är komplex (som Corona) så ge dig inte i kast med guesstimering förrän du fått göra en förstudie, även kallad Spike. Är uppgiften komplicerad kan du guesstimera på stående fot och är den enkel kan du estimera. Modellen Cynefin hjälper till här.

Samtidigt måste vi förstå att estimering endast har två syften som vi måste ta hänsyn till.

  1. Diskussionerna kring estimering inom teamet ger en större känsla för vad vi gör som team hellre än att alla gör sitt på egen kammare.
  2. Produktägare och stakeholders vill veta på ett ungefär när deras saker blir klara så de kan planera sitt arbete, det är vi skyldiga dem för de jobbar på samma företag som oss och vi alla är ett stort team som ska dra åt samma håll och inte tro att koden vi producerar har ett självändamål.

Länk till diagrammet och dess data

://

Håller du med? Eller inte? Diskutera här...