8 Agile Estimation Mistakes that Every Team Should Avoid

Agile estimation is an effective way to determine the effort required to complete a story, but there are a few common mistakes teams often do during sprints.

Agile estimation is becoming a core element of software project management. Development teams use estimates to prioritize work and set up achievable schedules, product owners use estimates to set up product roadmaps, and higher management use estimates to track budgets. Overall, agile estimation offers a lot of benefits. But it also requires that estimations are done rightly. Since, agile estimation, especially story points estimation, is used by almost every Scrum team, there are always some mistakes that teams unintentionally or intentionally do. In this article, we are listing down the 8 common agile estimation mistakes that should be avoided.

1. Points-Based Productivity Measurement

One of the common mistakes or misconceptions in the agile approach is that points are considered as a measure of a team's productivity or story's business value, which is totally wrong. Such misconceptions can lead to ineffective estimation or unexpected delays.

A team should not be compared based on the points it completes or its average velocity (i.e., average story points a team can accomplish in one sprint). Points just reflect the effort required to complete a story, not a measure of the team's capability to complete the story in a given time.

Although points are useful for a team's internal evaluation to see the efforts they have to put, still points are assigned based on the team's past experience with a similar story that required similar effort.

The way teams assign points to a story changes from team to team. A new agile team will definitely be weak in points estimation, but the gradual experience and past reference data can make them efficient and increase their productivity. In short, the main value points estimation brings to a team is helping them estimate how much work they can realistically complete in the upcoming sprint.

2. Over-Smart Estimation

All team members in an agile team showcase different levels of skill sets and experiences. Some of them are pro and fast, while others are beginners and slow. Therefore, often during a sprint planning meeting, a pro team member tries to show his/her capability by giving fewer points to a story, thereby showcasing less effort required. But due to that over-smart estimation, the team as a whole either fails to accomplish the goal or struggles hard to complete the story.

In such scenarios, it's important that team members are educated that the efforts they estimate are for the whole team not a single individual. There is no appreciation if you estimate a story with fewer points only to show your competence while letting the team suffer later on.

In the traditional business model, a company appreciates such employees who give unrealistic expectations based on their competency level. But the agile approach is completely different, and that's its beauty. Once an organization adopts an agile approach, the over-smart culture fades away, while the organization experiences a more productive, reliable, and realistic teamwork environment between all the teams.

So, to avoid team members estimating stories based on their competence, they must be reminded continuously to estimate the story based on efforts required by any member (pro or beginner) of a team. It might be struggling for new agile teams, but once members learn from their estimated points and actual efforts, the estimation would gradually become more efficient and team-centric.

3. Assigning Point Values based on Hours or Days

When teams shift to an agile approach, some of them are unaware of how points estimation works. So, what they do is they assign points to stories based on the hours it would take to complete that story. This approach is ok if a team is taking the first steps in the agile world. But if the team sticks with this approach for a long time, then it can start generating problems. They must soon understand that the points system is a relative scale estimation not an hourly scale one.

Just to be clear, "Points" is a measure of effort required to complete a particular story based on the efforts similar stories took in the past.

When an hour-based points estimation fails, the team's ability to use the hour's scale destroys, impacting both the productivity and the risk of long delays. For example, a team estimated a story to be completed in 4 hours, but it took them 8 hours to complete. So, they will start panicking about how to complete the next story in their estimated hours, when the first one didn't complete in the targeted hours.

To sum up, it is much fruitful for a team to quickly realize that the points estimation is relative-scale and it reflects the efforts need to complete the story not projecting the hours it would take. However, efficiency in points estimation also demands some time. It is the team's gradual experience that makes their point estimation efficient and makes them realize their average velocity.

4. One Sit All Estimation

During an estimation session, one common practice that most agile teams do is that they try to estimate all stories in one session. This approach is good if there are few stories to estimate and all the team members are available to join the session.

But the corporate world is globalizing and the trend of remote working due to the COVID-19 pandemic is also reshaping how team members collaborate. Some might be working in different time zones, while some might be unavailable to attend the session, causing the whole sprint planning process to get delayed. In addition, estimating all stories in one meeting session also seems less efficient. It is because not all members are capable of quickly understanding the story and providing estimates, especially the new team members. They need proper time to understand the story to allot the right points. So, the one-sit-all-estimation tactic does not seem an efficient approach if a team involves newbies or members working remotely or under different time zones.

One recommended solution is to provide members with stories beforehand so that they can have a prior understanding of the stories before coming to the sprint planning meeting. To save time even further, a team can be asked to study stories and provide points estimates before a given deadline. Afterward, the moderator can collect all members' estimates and see if a consensus is reached. If not, then a quick session can be conducted to re-estimate stories and reach a consensus. This approach of story point estimation is known as Async Poker.

5. Interlinking Business Value and Points

Agile teams should be clear about "Business Value" and "Points" and must not interlink them to create confusion.

Although an agile team is the one that estimates the effort required to complete a story, it's the product owner(s) who estimates the business value of a particular story and weigh other variables.

Unlike points, the business value of a story can change quickly due to multiple factors, including the order approach to complete stories. In fact, business value can also get changed when the team is working on the project during a sprint.

A product owner can even prioritize the backlog by considering the ratio of business value to estimated points. In addition, it can also play a motivational role for the team by letting the members know how much business value a particular story holds to the product owner.

Since business value can change at any moment, it is best for agile teams to keep business value and points separate from each other. A team should estimate a story based on the efforts it required, independent of that business value it holds to the product owner. This way, a team remains focused and productive, while can adjust its priorities later on based on instructions from the product owner.

6. Adjusting Values of Points

Story misestimation is a common mistake that teams do, especially those ones who have recently adopted the agile approach. The agile framework has a lot of benefits to offer, but its iterative nature is one of the leading ones. However, the iterative nature does not mean teams can adjust the values of points once they realize a story to be underestimated. Doing so just removes the whole purpose of the point estimation system.

The story points are the indicator of how the team understands the story using its knowledge and experience and then estimates the effort it will require to complete. So, when the actual efforts mismatch with the estimated efforts, it's a learning experience for the team so that they can estimate rightly in future similar stories. That's the main goal to achieve with the point estimated system.

If a team alters the values of points, then it is basically altering the history. Doing so reduces the team's capability to make their estimation skills efficient. So, when a similar story is discussed in the future, they will do the same old mistake if they have altered the values of points in the past. In short, keep the points values intact, learn from your misestimations, and improve your estimation skills.

7. Learning from Failure

Once a sprint session is completed, a team can sit together to discuss the overall performance of the sprint, how things shaped out, what were the negative aspects, and similar other elements. Failing to do so means that a team is not serious about learning from its past estimation mistakes.

The post-sprint discussion session is useful for teams to have a closer look at their stories estimation skills and set up reference points for the future. They can see which stories they underestimated or overestimated and what were the factors behind the prominent variation.

Probably, you will always hear from agile teams about stories that they overestimated with a very huge margin. For example, during a sprint planning meeting, a team came across a story that included a totally new/unknown technology. So, the team estimated that story with very little understanding. But when they started working on the story, they realized that the technology was straightforward to use and required just a negligible effort from them.

In addition, it is important that a team is informed about the product owner's plannings during the story and estimation development process. This way, they will not be blindsided during a sprint planning meeting. One quality a product owner should showcase is its beforehand discussion on future plans with the team while during the sprint session. A team can ask up different questions about future plans and then when the sprint meeting session begins, a team should come well-prepared to provide the right estimates.

8. Following Points Blindly

If a story does not adapt to the estimates, then it does not mean you have to follow the point estimates blindly during a sprint. You can adjust the backlog priorities and shift focus to other valuable stories.

Let's understand this with a help of an example. Consider a team that estimated one story to be straightforward because they thought that the available standard library will help to complete most parts of the story. According to them, simple integration of the library would be enough to cover up the story.

Later on, the acceptance criteria of the story became over the library capabilities. Gradually, the team was able to understand that they had to do more than just library integration to cover up the story. This misconception during story estimation and now the frustration in the team impacted the overall productivity and also made other stories of the same sprint at risk of being delayed.

In this type of situation, following points blindly will result in less productivity and delays. So, what the team or the product owners can do is adjust the backlog priorities in order to add up the actual effort that the story is demanding to complete. They can see if there are other stories with higher business value ratios and turn their focus towards them to remain productive and avoid unexpected delays.

Conclusion

Estimation is a must practice that agile teams do to remain focused and align their sprint goals. When an agile team is working together for a long time, their story points estimate becomes more accurate and realistic. However, new teams can and will do mistakes until they learn from their experience. So, make sure your team is aware of the above-listed 8 mistakes and try to avoid them as much as you could.