Agile Estimation: Principles

An estimation is questioned in software development for many years. How to estimate accurately & fast? And, is an estimation even necessary? Well, the question for thousands of bucks. Because estimation might be expensive. Especially in the age of changes.

Time as an estimation unit is wrong!

In our agile training, we used to ask trainee to visualize the amount of outcome they are able to finish per day and visualize it by hands.

Of course, the indicated amount will be different per person. Even it is just a feeling of the outcome, what you often see as a reaction is an immediate comparison.  The aim of the game is, to compare performance to yourself, not to colleagues.

The next questions are: „How big outcome have you been able to complete per day one year ago? What about the next year?“ 

What you would see are hands moving up and down. The most often reasons are:

• estimation is different based on the knowledge,
• experience is gained in one year,
• new technologies,
• new team,
• new tools.

Should you still ask teams to give you an estimate in time units? No. Small change influences the exact value. You can’t be more wrong than with hours, or man days as estimation unit!

Wisdom of a crowd

Try to ask 10 people for their estimation. Very often you will get 10 different results. Which one is correct? Well, the best one is the estimation of the team member who is going to work on the requirement.

But who is going to be once a sprint is started? We do not know that at all as we want to have shared knowledge in the team.

So this is a time to do the estimation differently. It is the time the to apply the wisdom of the crowds. You have to ask the team for one estimation value they agree upon.

Most of the team will estimate numbers which are pretty close. Few guys will estimate extreme values, either too small or too big. Statistics, however, tell us that truth is in the middle. Gaussians is simply Gaussians.

The beauty is not hidden in the result. The beauty is in the discussion about different opinions. A lot of assumptions are discovered during such team estimation.

The team inclines to the understanding of the scope and final estimation together.

Relative is fast & good enough

Customers are often interested in an estimation which they consider for „precise“ estimation. Due to the complexity of software, this is, however, very often not the feeling of the team. They provide a rough estimation. So if the team provides hours or man-days, the customer might have the wrong assumption.

We do not have time to provide the precise estimation in the time unit. It is too costly in case of later scope changes. We need to be fast with it, therefore we need to find something else.

An experience shows that people are better with the relative comparison. The brain uses it daily for quick decisions. Do you drive a car? Well, your brain doesn’t calculate physics formulas. It compares relative position of your car and based on that you act. In most cases it works, in some cases, you will get lessons learned.

Relative estimation example

Let’s look at buildings of Dubai city. We want to compare the height of the buildings relatively. Our reference building we want to use for comparison will be the building marked with number 1.

Let’s agree about principles for the estimation:

1. We consider only the height of the building.
2. Antennas are considered as part of the building hence they are included in the estimation.
3. We do not consider perspective, every building stands on the same line.

How many times is the building A higher comparing to Building 1 in your opinion? Well, most of the answers in our training are 1, they are equal.

What about the building B? The answers are typically different – 0.5, 0.7, 0.4 times. Our opinions are different because the scale is too wide, too much detailed. Therefore let’s fix that with the following Planning Poker scale (defined by Mike Cohn from Mountain Goat Software).

What about now? The most answers are now the same – ½.  Now let’s compare other buildings to three already estimated buildings.

Hopefully, you realized how fast your estimation was now. You should compare buildings not just to the reference building, but to other buildings as well. This will result in groups of buildings of similar sizes. They will not be precise in centimeters, but that’s fine as we do not need that for the rough planning.

Time unit in proper time!

Details of user stories are evolved over time. At the beginning, they are maybe just the titles. Later, in release planning, the product owner should describe them in user story format. In the sprint planning, there should be all details as acceptance criteria.

In release plan, user stories are being considered as candidates which might be later pulled out of the release. Due to that, it doesn’t make sense to estimate user stories with time unit. In such case, we’ll waste a lot of effort for the estimation, especially in case some user stories will not be implemented later due to changes of plans.

All of that is a reason for estimation with story points. Yes, those numbers on the cards.

Time estimation should be provided at the latest moment (if even), not earlier than in sprint planning.

Conclusion

The constant changes are the reason for fast and accurate, not precise, estimation. The team should estimate the value together to support knowledge sharing, work distribution, and faster planning. Story point should be used for preplaninng and release planning sessions while time (if even) for sprint planning sessions.

Read more on estimation

Part II: Agile Estimation: Real Life

Part III: Agile Estimation: Story points, Hours or #noestimate?