Estimation is a wasteful activity once your teams are predictable

Once teams can reduce their Cycle Time and Lead Time sufficiently that their work item size becomes consistent and predictable, it is a simple task to know how much work they can get through given a timeframe, and also to know how long it will take to complete a backlog of work.

There can be lots of excitement and enthusiasm to cut out estimation altogether. But without the right conditions, it falls apart very quickly, and people revert back to expecting estimates.

NoEstimates is a movement that relies upon data rather than people’s guess work to know how long it will take to complete work. Being data-driven, it removes the uncertainty and bias that produces many of the errors when estimating work.

So what are the right conditions to begin using NoEstimates?

1. You must have long-standing teams, and work brought to the teams. i.e. no pulling individuals onto other projects or outside work. = Team cohesion

2. You need to have a fairly consistent rate of work, measured either by throughput at regular intervals, or cycle time / lead time. = Consistent work size

3. The work shouldn't be completely new to the team and require lots of analysis or learning new tech stacks. = Maintain the domain

4. The management team should accept and work with the uncertainty of probabilistic estimation. = Patience to learn

Since we know that estimation is never accurate (see previous post on this), then we might as well move on and claim back the time spent estimating.

Here's what you can start with now:

➤ Help teams reduce the size of their work items so the they become small and consistent. Measure cycle time / lead time.

➤ Build team cohesion and don't pull individuals out of teams.

➤ Bring consistent work to the team based upon their domain.

➤ Measure throughput rates, and consistency given the same timeframe. e.g. 1 Sprint.

➤ Apply NoEstimates to the next chunk of work the team does.

Questions and Answers

Question:

How do you suggest calculating probabilistic estimation without estimations?

Answer:

Great question. In NoEstimates, rather than ask individuals or teams to examine the work and form an educated opinion, they instead use historical team data to calculate the throughput of the team, and apply that to a backlog of work.

The reliability of such an approach depends upon the consistency of the team in terms of their throughput. This requires that you have long-standing cross-functional teams, and bring work to them that is of reasonably consistent nature. The teams break down the work into a backlog of completable items, and those items are all roughly of the same size.

When work item size and throughput are reasonably consistent, the team's predictability is reliable, and a probabilistic forecast is dependable.

This forecast is still a kind of estimate, because there is no guarantee it will be completely accurate, but now it's based in data rather than a person's opinion.

Question:

How can you use historical data if your team is using #NoEstimates? Doesn't that mean there is no historical estimation data or information available to base future comparisons and probabilistic forecasts?

Answer:

The data used is a measure of the amount of work a team can get through in a given timeframe.

The data used is either Lead Time (sometimes it's Cycle Time) or Throughput - it's a measure of the amount of work a team can get through in a given timeframe. With stable teams this is a reliable predictor of completion rate. This data is readily available in modern workflow management tools like Jira.

Question:

There is always a chance that someone leave or join the team. What would you do to handle this situation?

Answer:

The long-standing cross-functional team is maintained if a person leaving is replaced. The stability of throughput might vary for a time, but will generally restabilise to the same throughput as prior. If the target is stable teams, then stability can be achieved.

Maintaining stable teams is key to successful large scale delivery.

Question:

In which units are the estimates? If delivery dates need to be predicted, there are only two options:

1. Estimate in a time unit

2. Estimate in other units and have a conversion rate to time units.

Answer:

The process is to arrive at an average Lead Time per completed User Story, end to end - backlog to Done.

Average Lead Time can be calculated by averaging the amount of work completed in a set period, e.g. 1 week. You might average over multiple weeks.

This number can fluctuate heavily from period to period, which may not give you the predictability needed to make a reliable probabilistic forecast.

Instead you can just use Lead Time averages. You can look at Lead Time Distribution to see how varied it is, and you can work towards reducing the variance when you have stable teams.

Once you have reasonable consistency, you can just use Lead Time averages to estimate a backlog of work. It assumes that the team can reliably break down a large body of work into consistently sized work items.

Through stable teams you can reduce a lot of the uncertainties, skill constraints, dependency problems and risks you mentioned.