MISsing the Point with Agile Estimation

Before I get started, I'd like for you to take a look at this definition:

es·ti·mate

verb - 3rd person present: estimates - ˈestəˌmāt/ - roughly calculate or judge the value, number, quantity, or extent of.

noun - plural noun: estimates - ˈestəmət/ - an approximate calculation or judgment of the value, number, quantity, or extent of something.

I have noticed that a lot of time and energy go into generating estimates . Quotes such as these often materialize:

"You need to get your estimates more accurate"

"I need these estimates to be on the money so I can show them to (insert someone important)"

Everyone is then all spun up and at least one person ends up looking like this:

Sadly, this type of frustration is something I'm sure many of us have encountered.

In this post I'll be focusing on estimation at the Product Backlog Item level, rather than the granular details (often referred to as "tasks") that many teams dive into when creating a Sprint Backlog.

A pattern seems to exist with teams and their approach to estimates, and it's challenging to break out of. This pattern I've observed looks similar to this (your results may vary):

Estimates are MISunderstood...

The understanding of what an estimate actually represents mixed with other factors can contribute to the overall frustration around estimating backlog items. Some of these factors could include:

Lack of a shared understanding of the backlog item being discussed
Inaccurate perception that this "guess" is actually a commitment
Belief that this estimate can be made in a vacuum instead of relative to other items
Some wacky mapping exercise where their estimates represent (think points-to-hours arguments)

Try to be aware of these factors as well as what an estimate represents as a starting point, and have some constructive discussion about the backlog items that are being discussed.

...as a result, these estimates are MIScalculated...

If there is a lack of understanding of what the estimates represent, a number of factors can contribute to these guesses being calculated in different ways including:

Team guesses start coming from one person instead of the team as a whole
Team guesses come from someone other than those who are doing the work
Guesses get extended to leave time for the inevitable impediment
Guesses get shortened because the team does not want to appear they are up for the job

Avoid some of these situations by working together to create an environment focused on trusting one another with respect to estimates. "Whatever you guys say, I trust you!" is a powerful phrase!

...which causes these estimates to be MISinterpreted...

A lack of understanding and improper calculation can result in these guesses being interpreted in a number of strange and potentially negative ways, for example:

A Team with a higher velocity is clearly doing more work than one with a lower velocity
Teams cannot agree on a common estimate, so the team is not built correctly
When guesses don't map to perceptions then more time is needed to gain accuracy
Teams that accomplish estimated items clearly guess better than teams that don't

Try to get a handle on what you are looking at with respect to a team's guesses and see what they represent, and don't start comparing apples to oranges. Even more importantly, make sure you are actually looking at an apple! :)

...resulting in the information to be MISused...

All of the factors above can contribute to the information being held against teams in a number of ways. Factors such as these can put teams in a tough spot:

Tying these guesses to team / individual performance, instead of as a short-term planning tool
Working to RAISE velocity over time instead of trying to STABILIZE it
Linking any financial reward to these guesses such as payment or bonus benefits
Approaching these guesses from a governance or punitive state of mind

Imagine hearing someone say this with respect to estimation:

"We need to have some hard conversations with teams and individuals who can't estimate right"

I'm paraphrasing this quote, but it's one I've heard and it was pretty jarring to say the least.

We have to work together as a community to break this cycle of behavior with how organizations approach agile estimation.

When I have discussions with those who are really interested in metrics, I always ask:

"That's great! Now, what do you want to do with some of these metrics, for example how are they used?"

This question has led to a number of different answers (some from a good place, some not) and is part of the inspiration for this post.

When approaching these estimates (or "guesses") I'd ask that you keep some things in mind:

Teams use these guesses to figure out how much they can take on

The individuals doing the work are the best sources for these guesses

Teams that shorten or lengthen their guesses is an indicator of your environment

Having an environment where trust is valued is key for these activities to be productive

At the end of they day, if teams can get an idea of what they can take on for the next segment of time (sprint, iteration, whatever label you like) then they can find an amount of backlog items that will keep them engaged while not burning out. From the agile manifesto:

Agile processes promote sustainable development.

The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.

http://agilemanifesto.org/principles.html

Let's work together to avoid wasted energy and frustration around estimation discussions and instead focus on delivering value to those that benefit from these items being completed.