Estimation has been questioned in software development for many years. How can an estimate be made accurately and quickly? And is estimation even necessary?
Well, that is 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 asked trainees to visualize the number of outcomes they could finish per day by hand.
Of course, the indicated amount will be different for each person. Even if it is just a feeling of the outcome, you often see a reaction as an immediate comparison. The aim of the game is to compare your performance to yours, not to your colleagues. The next questions are:
The next questions are: “How big an outcome were you 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 common 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 estimation of time units? No. Small changes influence the exact value. You can’t be more wrong than with hours or man-days as estimation units!
Wisdom of a crowd
Try asking 10 people for their estimation. Very often, you will get 10 different results. Which one is correct? Well, the best one is to estimate the team members who are going to work on the requirement.
But who will be once a sprint is started? We do not know that at all, as we want to share knowledge within the team.
So this is a time to do the estimation differently. It is time 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 pretty close numbers. Few guys will estimate extreme values, either too small or too big. Statistics, however, tell us that truth is in the middle. Gaussian is Gaussian.
The beauty is not hidden in the result. It is in the discussion of different opinions. During such team estimation, many assumptions are discovered.
The team is inclined to understand the scope and final estimation together.
Relative is fast & good enough.
Customers are often interested in an estimation that they consider a „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 a precise estimation of the time unit. It would be too costly in case of later scope changes. We need to be fast with it, so we need to find something else.
Experience shows that people are better at 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 the relative position of your car, and based on that, you act. In most cases, it works; in some cases, you will learn lessons.
Relative estimation example
Let’s look at the buildings in Dubai. We want to compare the height of the buildings relatively. The reference building that we want to use for comparison will be the building marked with the number 1.
Let’s agree on principles for the estimation:
- We consider only the height of the building.
- Antennas are considered as part of the building; hence, they are included in the estimation.
- We do not consider perspective; every building stands on the same line.
How many times is Building A higher compared to Building 1, in your opinion? Well, most of the answers in our training are 1, they are equal.
What about 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).
-> Use Agile ToolboX in your planning sessions
What about now? Most answers are 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 have evolved over time. In the beginning, they are maybe just the titles. Later, in release planning, the product owner should describe them in user story format. In sprint planning, all details should be included as acceptance criteria.
In the release plan, user stories are considered candidates that might later be pulled out of the release. Therefore, it doesn’t make sense to estimate user stories with a time unit. We’ll waste a lot of effort on the estimation, especially if some user stories will not be implemented later due to a change of plans.
All of that is a reason for estimation with story points. Yes, those numbers are on the cards.
Time estimation should be provided at the latest moment (if ever), 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 preplanning and release planning sessions while time (if even) for sprint planning sessions.
In part II, we are going to present an estimation SW sample with story points.
