To Estimate Or Not To Estimate

Over the last few days, a debate has been going on about #estimates and #noestimates. As with all other basic concepts, this misunderstanding also comes from the lack of knowledge about basics of lean and agile.

Jeff Sutherland covers this topic beautifully in this webinar Points vs. Hours.

I am just going cover some basics below:

Humans are not good at estimating hours.

Then why should we spend time on estimation?

There are two very important reasons.

  1. To Determine Teams Velocity – Speed of Delivery
  2. A Consistent Measure Of Team’s Output

Both of these reasons come from a single source – Edward Deming and Statistical Variance techniques.

Measure Statistical Variance

1. Team’s Velocity

A team should be able to measure how much functionality it can produce every sprint, every week, every day. Remember, focus is not on architecture diagrams or documents. But actual usable production ready functionality. The goal of Scrum team is to increase this speed of delivery.

This serves two purposes. First, it allows product owner to approximate and plan for product release. Second purpose is Kaizen or Continuous Improvement. It allows team to work towards continuous improvement. That is if they are delivering x number of story points every week, how can they work towards delivering 2x story points or even 4x story points. Please note this is not management asking them to deliver faster. It is the team, which by removing impediments (many times organisational impediments) works towards ever increasing speed.

For example, one team used to deliver 10 story points a week. Eventually, with lot of improvements, they started delivering 20 story points a week. After another six months, they started delivering 40 story points. And soon they were aiming for ten story points a day. At this stage, the team was addicted to hyper productivity. It was self-sustaining and self-improving. Always looking to increase the speed of delivery.

2. Continuous Measure of Team’s Output

It is important to estimate teams output because if you don’t estimate how would you come to know if you have delivered less or delivered more? In both cases, you should be able to calculate Statistical Variance and find reasons for this variance. Again, to continuously improve. If you want your team to be hyper productive, you would want to find and fix root causes for this variance. Not simple patch work or fixes but correct the root cause, which would lead to increased velocity.

This again is Kaizen or continuous improvement.

#noestimates is not an option.

These are the only two reasons for estimation. No estimation is really not an option. If you don’t measure, you will be never able to find out variance. Variance from what was estimated. And if you can’t calculate variance, how do you find what caused that variance and how to fix it?

These two are the only reasons for estimation. Everything else is just to keep management happy.

So, to answer Lean Shakespeare’s question

To Estimate Or Not To Estimate

The answer is always Estimate or risk being stagnant, not improve, not innovating and eventually being thrown out of the market.

Leave a Reply