I spend a lot of time working with various product development teams, a common complaint is that estimates are usually wrong.. How can we get better estimates… Or ensure that teams deliver against estimates.

Product Managers and Project Managers are typically trained to create and then manage timelines. Projects are tracked against adherence to these plans.

In Sprint planning (for teams using Scrum) I often observe stories broken down into tasks.. Tasks estimates done in hours and tasks assigned to people throughout the sprint. The sprints are carefully planned and loaded to achieve as close to a 100% utilisation as possible. Usually the end result of the sprint looks very different to what was planned… But why?

First I want to talk about variability and the affect it has on conventional timeline management.

Image 50 coin flips :-

• For every head we add 1

• For every tail we subtract 1

After 50 flips what would we think the cumulative value to be?

Our gut instinct or understanding of averages suggests that it should be around 0 - However as can be seen from above that’s often not the case. Perhaps 50 is too small a sample size - and over time the laws of averages will bring it back under control? So I repeated, this time for 1000 flips.

And for those who still have doubt - I repeated again, This time for 10,000 flips.

Our assumptions about randomness and variability are often wrong! But why is any of this important?

Despite our assumptions the cumulative total is spinning randomly out of control… Unfortunately as we can see randomness does not correct this effect.

In my example we have limited variability - Each toss of a coin has only 2 possibilities. In Product development how much variability do we have?

We break each task down into ever more granular steps in an attempt to improve our estimates - But this is driven by a lack of understanding of the statistics around granular schedules. The coefficient of variation against each step become higher and higher. The effect? High variance and low adherence to plans.

So what do we typically do? We introduce buffers to our plans! Buffers are usually an economic mistake. When we add buffers we trade a decrease in uncertainty with an increase in cycle times, this is nearly always a bad trade as you are effectively increasing the cost of delay reducing overall profit.

This scenario was once common place in manufacturing before the eventual adoption of techniques such as TPS (Toyota Production System)

In product development we have considerably more variation than we do in manufacturing which is typically a repeatable process so the affect is further amplified.

Without an understanding of the commutative effect of variance over granular schedules we’ll often attempt to plan with Tetris accuracy (left) however the result will often resemble the 2nd image (right).

This lack of understanding of variance and blindness to queues leads to ineffective project management. Focussing on flow and active management of queues allows for far greater control over cycle times.