Estimating Vs Forecasting : Demystifying in Agile Projects (Part 1)
Sitting in CSPO class, heard that in present agile projects, it’s customary to forecast rather than estimate?
Does it sound similar or something weird. Discussion ensured but there was no clear thoughts what is what and when to use. Off-course the class or the time was not ripe enough to take discussion to next level
So what is estimation and what is forecasting?, why, when , how, too many questions. let’s try to demystify one by one
Estimating Vs. Forecasting — The Difference
What is an Estimate: The estimate includes all the work to complete a feature — analysis, design, dev, testing, integration, release etc. Others may think of the estimates as
- Estimation is an INFORMATION
- Estimates are used for FORECASTING
- Usually teams use ‘story point’ estimates for the features
- Most teams uses Fibonacci series for Story Points ie a relative measure
- Its a relative estimate and simple , fast and consistent
- Collaboration, assumption and Knowledge is key for small estimates
- Teams becomes experienced after estimating for a time.
- Its a short feedback loop
- “How long” is an example of estimate
What is a Forecast : Usually a forecast is a guesswork, it may be based on past experience, metrics, and projection tools. Others may think of the forecast as
- Forecast is a EXPECTATION
- Multiple estimates can be used for FORECASTING
- Its a commitment, ie commitment to delivery to a fixed scope, fixed cost or fixed date
- Forecast= Story Point+Velocity
- Used for Time, Budget and a degree of Confidence
- Used for Short Term or Long Term work
- In some instances, Estimates and Forecast could be same
- “When its Done” is an example of Forecast
In a nutshell or summary
Some Practical Notes on Estimation
- Note that most of the teams don’t estimate Tasks. Rather its User Stories that are estimated but forecast is a projection for the feature/release completing and not task.
- With high level estimates , one can estimate the release timelines
- low level estimates are required during the sprint planning session for items that can be delivered in 2 weeks ( 1 Sprint ) timeframe.
- You don’t estimate for ‘Technical or Functional Spikes”. They are estimated outside of Planning session But how do you budget for these is a different question.
- If the estimated user stories goes past a sprint, the relative task are moved but not the whole story ie logging can be done in next sprint but the feature can be in Prod in current Sprint
- Use ‘feature flags’ if Story Points estimate is 13 or high. Not all teams does this though
- How do you estimate for the first time. The teams should start somewhere and could just produce a rough estimate. As said teams become more experience with time
For more practical deep dive into Estimates, read my old post
“To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.” — Chinese proverb”
To be continued