top of page

Progressiv planering - hur du undviker schweizerost-estimat 🧀

FörutsÀgbara resultat kommer inte frÄn rigorös analys och precisa estimat. Planering och estimering i komplexa domÀner krÀver progressiv planering, eller sÄ slutar det med planer fulla av hÄl - som schweizerost.

I den förra artikeln beskrev jag skillnaden mellan precision och korrekthet, och varför korrekthet alltid Àr viktigare. Att ta hÀnsyn till detta och agera dÀrefter - att kontinuerligt förbÀttra precision utan att göra avkall pÄ korrekthet - Àr vad jag kallar progressiv planering.

Att planera progressivt betyder att man mÄste ta till sig nya sÀtt att tÀnka kring planering och estimering, men lÄt inte det hindra dig. Dom potentiella vinsterna Àr enorma.

I den hÀr guiden fÄr du lÀra dig:

  • Hur för precisa estimat för tidigt leder till schweizerost-estimat.

  • Hur du förbĂ€ttrar precisionen över tid.

  • Vad man ska göra och vad man inte ska göra nĂ€r man planerar progressivt.

  • Hur en progressiv plan ser ut i olika faser av ett projekt.

  • Hur man kan hantera scenarion med lĂ„st innehĂ„ll och lĂ„st pris.

LÄt oss först titta pÄ vad schweizerost-estimat leder till.

Varför schweizerost-estimat har betydelse

Att försöka fÄ ut för precist data frÄn organisationen, oavsett hur viktigt det verkar vara eller vem som ber om det ("kunderna krÀver det") leder oundvikligen till schweizerost-planer. Misstro, missade deadlines och dÄlig kvalitet följer som ett brev pÄ posten. Det behövs en organisationen med ryggrad, och disciplin frÄn stakeholders, för att inte gÄ i den hÀr fÀllan.

Vad orsakar schweizerost-estimat?

Planering behövs. Man bör definitivt planera i förvÀg. Problemen börjar i samma stund som man tror att tillrÀckligt noggrann planering i början Àr tillrÀckligt, och ger hög precision-hög korrekthet estimat - och att skÀlet till att det inte lyckades förra gÄngen sÀkerligen Àr att man inte var tillrÀckligt rigorös, eller att teamen saknar nÄgon analys- eller estimeringskunskap.

NÀr man gör en detaljplan i förvÀg försöker man bryta ner och identifiera allt arbete. Cirklarna nedan illustrerar identifierat scope och relaterade estimat (möjligen story points). Teamet har försökt identifiera allt "jobb" dom behöver göra.


Den hÀr typen av djuplodande detaljplanering leder oundvikligen till missat scope (det gula omrÄdet nedan). Det hÀr Àr en inneboende egenskap i mjukvaruutvecklings komplexa natur, som inte gÄr att analysera eller planera bort.


SÄ hur undviker man schweizerost? Det Àr bÀttre att i början nöja sig med grövre högnivÄ-estimat (den stora cirkeln till höger). Med andra ord: vid varje given tidpunkt mÄste precision och storlek pÄ det man estimerar matcha osÀkerheten.

SÄ hur förbÀttrar man precisionen och Ästadkommer bÀttre prognoser? Progressiv planering till rÀddningen! (LÀgg till din favoritsuperhjÀlte hÀr.)

Progressiv planering

Progressiv planering innebÀr att hela tiden medvetet förbÀttra estimat och prognoser under ett projekts livstid.

Det finns tre regler att följa:

  1. Tappa inte korrekthet ur sikte

  2. Beakta hela tiden allt scope

  3. AnvÀnd empiriskt data för att förbÀttra prognoser

Dom hÀr reglerna har implikationer pÄ planering - bÄde nÀr det gÀller vad man ska göra och vad man inte ska göra.

Tappa inte korrekthet ur sikte

Att inte slÀppa fokus pÄ korrekthet innebÀr att man mÄste göra avkall pÄ precision initialt. Se ocksÄ till att kommunicera precisionsnivÄn pÄ rÀtt sÀtt.

​Gör đŸ‘đŸŒ

LĂ„t bli đŸ€šđŸŒ

AnvÀnd enheter och storlekar som matchar precisionen (t.ex. veckor).

Dela estimat i enheter som ger en falsk kÀnsla av precision (t.ex. timmar).

Utnyttja intervall.

Kommunicera enpunkts-estimat.

Estimera med rÀtt storlek pÄ objekt.

Försök bryta ner och estimera allting i detalj frÄn början.

Beakta hela tiden allt scope

För att kunna hÄlla allt scope i huvudet mÄste man fundera pÄ storleken pÄ saker. Siktar man pÄ för mycket detaljer för tidigt sÄ kommer man - medvetet eller ofrivilligt - ignorera delar av innehÄllet.

Att fokusera pÄ en delmÀngd och lÀgga resten i en blandad hög med "framtida arbete" skapar en stor hink med lÄg precision-lÄg korrekthet estimat. Försöker man Ä andra sidan inkludera allt men pÄ en för hög detaljnivÄ sÄ missar man saker, och fÄr ett mentalt sammanbrott nÀr man försöker hÄlla koll pÄ alltför mÄnga saker samtidigt.

Gör đŸ‘đŸŒ

LĂ„t bli đŸ€šđŸŒ

Dela hela tiden saker sÄ att varje ny del representerar nÄgot vÀrde eller funktionalitet.

Skapa generella hinkar i backlogen (till exempel "ÄterstÄende job" eller "framtida arbete").

Dela upp hela projektet i omrÄden/teman.

Strunta i att estimera eller fÄnga upp delar av scope.

Dela kontinuerligt upp arbetet i mindre och mindre delar som representerar verkligt arbete.

Dela upp arbetet i "del 1", "del 2" osv.

AnvÀnd empiriskt data för att förbÀttra prognoser

Att anvÀnda empiriskt data för att förbÀttra prognoser över tid förbÀttrar precisionen, sÄ att fÄ fram empiriskt data mÄste vara en prioritet. Det betyder börja jobba - helst med teamen som kommer implementera hela projektet - sÄ snart som möjligt.

Om teamen har historik av liknande jobb, sÄ borde man vara i en fördelaktig position att ta fram bra estimat fort. Det blir svÄrare och svÄrare ju mer arbetet och/eller teamuppsÀttningen Àndras.

NÀr man Àndrar pÄ team - exempelvis lÀgga till eller ta bort medlemmar - skapar man en ny kontext och ogiltigförklarar eventuellt empiriskt data man hade. Det hÀr Àr ett skÀl till att stabila team diskuteras inom mjukvaruutveckling. Det betyder inte att man aldrig ska Àndra pÄ teamen, men gör det avsiktligt och fundera pÄ hur det pÄverkar prognoser och effektivitet.

Att om-estimera arbete nÀr man uppdaterar prognoser skulle vara omstÀndligt och bortkastad tid. Relativa estimat gör det möjligt att förfina prognoser utan att estimera om. Man behöver bara omberÀkna hastigheten vilken hÀrleds frÄn estimaten - den estimeras inte direkt.

JÀmför med etapperna pÄ en resa. Det gÄr att estimera storleken pÄ etapperna relativt varandra utan att veta hur snabbt du Äker - kanske har du inte ens bestÀmt fordon - men nÀr du börjar Äka kan du berÀkna hastigheten och göra en prognos hur lÄng tid resan kommer ta. Etappernas relativa storleken Àndras inte.

Empiriskt data och relativa estimat antyder ocksÄ att arbeta inkrementellt och iterativt, och att leverera fungerande mjukvara kontinuerligt. Det Àr dessa inkrement som lÄter dig berÀkna hastighet.

​Gör đŸ‘đŸŒ

LĂ„t bli đŸ€šđŸŒ

Börja arbeta sÄ snart som möjligt.

Spendera mycket tid pÄ förplanering med lite vÀrde.

Kommunicera uppdateringar allt eftersom prognosen Àndras.

LÄtsas om att den initiala planeringen hÄller.

HÄll teamen stabila, och nyttja befintliga team om möjligt.

Omorganisera och Àndra teamuppsÀttning slumpmÀssigt.

Estimera relativt - hÀrled kalendertid.

Estimera direkt i kalendertid.

Ett exempel

SĂ„ hur ser progressiv planering ut under olika delar av ett projekt?

Uppstart

I början mÄste man offra precision till fördel för korrekthet. För att kunna ta allt scope i beaktande sÄ bryts arbetet ner till stora omrÄden (kanske "teman" eller "epics") och estimeras relativt varandra.

Om man bygger ett Àrendehanteringssystem sÄ skulle omrÄden kunna vara:

  • Ärendehantering

  • Dashboards

  • Rapporter

  • Import och export av data

  • Sökning och filtrering

  • Projektadministration

I bilden nedan representerar varje cirkel ett omrÄde tillsammans med dess initiala högnivÄ estimat (möjligen "epic points").

Identifiera ett eller tvÄ omrÄden dÀr det Àr lÀmpligt att börja. Till exempel baserat pÄ risk, genomförbarhet eller prioritet. De valda omrÄdena bryts ner till mindre delar, dÀr varje ny del representerar faktiskt arbete.

Ärendehantering skulle kunna brytas ner till:

  • Visa Ă€rende

  • Skapa Ă€rende

  • Uppdatera Ă€rende

SÄ smÄningom Àr arbetet uppdelat sÄ att det kan implementeras av team. Illustrerat nedan av mörkare gröna cirklar. "Visa Àrende" skulle exempelvis kunna delas upp i:

  • Lista Ă€renden

  • Visa ett Ă€rende

  • Skriv ut Ă€rende

Mellanspel

Allt eftersom arbetet fortskrider blir saker fÀrdiga, illustrerat med grÄa cirklar nedan. NÀr omrÄden börjar bli klara bryts nya omrÄden ner och förbereds för att implementeras.

SÄ hÀr fortsÀtter det genom projektets livstid. Alla fÀrdiga delar genererar empiriskt data som kan anvÀndas för att uppdatera hastigheten och förbÀttra prognoser.


Slutspel

I slutet Àr antagligen det mesta klart. Eftersom saker har utvecklats iterativt och inkrementellt Àr det lÀtt att fatta affÀrsbeslut om att avsluta projektet och strunta i saker som inte lÀngre behövs. Nya krav kan Àven ha upptÀckts lÀngs vÀgen. I bilden nedan representerar de tvÄ blÄ cirklarna arbete som inte slutfördes. Notera att de aldrig bröts ner i detalj eller pÄbörjades.


Fast scope - fastpris

Kunder föredrar ofta fastpris-kontrakt. Det ger illusionen av trygghet ("Jag vet exakt vad jag fÄr och nÀr") men sanningen Àr att det oftast Àr sÀmre för kunden och leder till:

  • DĂ„lig kvalitet

  • Höga kostnader

  • Skillnad mellan mĂ„lbild och faktiskt leverans

En utmaning med fastpris-kontrakt Àr att leverantören vanligtvis ombeds göra ett vÀldigt precist estimat frÄn början. Leverantörer hanterar detta pÄ tvÄ sÀtt:

  • En buffert lĂ€ggs till pĂ„ estimaten

  • En Change Control Board (CCB) inrĂ€ttas för att hantera och förhandla Ă€ndringar

Dessa nödvÀndigheter förhindrar dock inte progressiv planering.

Det Àr oavsett fördelaktigt att jobba inkrementellt och iterativt. Att inte ha allting pÄgÄende samtidigt underlÀttar affÀrsbeslut. NÀr kunden ber om Àndringar (Àven om det Àr via byrÄkratiska förÀndringsprocesser) sÄ hjÀlper det om inte allting rör pÄ sig, och att veta vad som Àr fÀrdigt - och vilket arbete som inte har pÄbörjats Ànnu (vilket gör det enklare att byta ut).

Det minskande vÀrdet frÄn rigorös förplanering betyder att man vill hÄlla den lÀttviktig och i stÀllet fokusera pÄ att pÄbörja arbetet.

AnvÀnd olika tekniker parallellt för att fÄ bÀttre prognoser frÄn start. Till exempel:

  • Estimera stora omrĂ„den relativt varandra, till exempel med "epic points".

  • Gör prototyper och genomlysningar för att verifiera genomförbarhet.

  • Titta pĂ„ t.ex. antalet UI-vyer eller API:er - estimera kostnaden för en och multiplicera.

  • Utnyttja eventuellt empiriskt data som finns.

  • Gör en konfidens-omröstning med teamen.

Se ocksÄ till att separera estimat och affÀrsbeslut. Som affÀrsÀgare vill du kanske ta en kalkylerad risk, men pÄverka inte organisationen att ta fram fantasiplaner och lÀgre estimat. Det Àr ok att stÀlla frÄgor som "Vad hÀnder om vi tar bort det hÀr?" osv, men ifrÄgasÀtt inte estimaten.

Avslutningsvis

Progressiv planering och att starta arbetet tidigt har fördelar jÀmfört med rigorös förplanering:

  • Man fĂ„r ett försprĂ„ng pĂ„ implementationen.

  • Man fĂ„r empiriskt data snabbare vilket möjliggör mer pĂ„litliga prognoser tidigare.

  • Teamen involveras tidigt och kommer upp i fart snabbare.

Into desto mindre verkar det vara förvÄnansvÀrt svÄrt att göra det hÀr i praktiken. Tryck frÄn stakeholders, ett fixerat tankesÀtt kring hur man planerar, och organisatoriska begrÀnsningar kommer i vÀgen. Ingen hjÀlps av orealistiska planer dock: inte utvecklingsteam, inte affÀrsÀgare, och definitivt inte kunder.

Hur planerar ni? Vad hindrar er frÄn att planera progressivt?



Färdiga utbildningar inom agilt eller en kurs anpassad till era behov?

  Produktägare

Till dig som är

bottom of page