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 continued




Not a geek but interest include one , i write on practicing work that genuinely reflects the experience | Runner | Avid Walker

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Build Better Things, Faster

Smag Grotto [No Spoilers]

Tutorial 1: OOPs in Python — Creating classes and objects

Google Cloud Serverless technology never sleep

👨‍💻Launch GUI container on the Docker

AMD Could Bring Dual-Socket Support To Ryzen Threadripper ‘Pro’ Platform — Up To 128 Cores & 4 TB…

Add value to your chatbots through phone calls

The Full Roadmap to program with ruby

roadmap to ruby programming الإبحار في البرمجة بلغة روبي

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kumar Anil

Kumar Anil

Not a geek but interest include one , i write on practicing work that genuinely reflects the experience | Runner | Avid Walker

More from Medium

Keep Your Metrics Simple

Understanding the Power and Weakness of “Why”

Product Trio in a Remote World

The Problem Space vs me…