Väldigt ofta vill man ha en bild av hur man ligger till med ett utvecklingsprojekt. Vi försöker säkra leveranser på utlovad tid genom att hantera de saker som hindrar oss att nå det planerade målsnöret. I allt utvecklingsarbete finns många okända faktorer, faktorer som det är omöjligt att inse från början. Vi vill dessutom göra det möjligt att förändra innehållet när vi inser nya saker eller prioriterar annorlunda.

Vi kommer aldrig kunna vara helt säkra, men om vi har en ordnad backlog med värdefulla features (se till exempel https://www.agilealliance.org/glossary/invest/), så kommer vi i alla fall kunna leverera de mest prioriterade ärendena, de som ligger överst.

En uppskattning av omfattningen av projekt i mantimmar visar sig oftast vara väldigt fel. Genom att använda jämförande estimat kan man minska detta problem.

Ännu bättre är att använda relativa estimat, alltså att jämföra varje ärende med andra och ge det en siffra relativt storleken på andra. Om vi gör det konsekvent så kommer historiken att visa oss vad våra estimat kan betyda i verklig tid.

Oavsett hur man gjort uppskattningen är det väsentligt att man kontinuerligt gör nya prognoser baserat på verklig progress och synliggör dessa. På så sätt kan vi justera vår planering och utfästelser till omgivningen i enlighet med det. Det är också mindre viktigt att ha estimat för ärenden som är lägre prioriterade, så estimeringen kan göras löpande.

Det kommer att ske förändringar i både vad vi hinner med och vad vi vill göra. Med en fast tidsplan och innehåll är det svårt att hantera både naturliga förändringar (kunden förstår sitt behov bättre) och oförutsedda händelser (strömavbrott i serverrummet).

Om man riskerar att missa deadline, finns det bara ett realistiskt sätt att nå den och det är att minska innehållet. Om det istället är ett fast innehåll man vill ha så måste man istället justera slutdatumet.