Agile Estimations: Common Pitfalls and Patterns to Avoid | David Tzemach
Updated: Mar 2, 2022
When a team starts using relative estimations, we can expect to see some mistakes. In this article, I want to share some common pitfalls and destructive patterns often seen in Agile teams related to their estimation process. If you identify one of the items below in your process, make the necessary adjustments to mitigate it.
Partial Vs Whole Estimations
Before starting the estimation process, the SM must remind team members to estimate the total amount of work involved in the story rather than just their part of the work. If we don’t get this right, the estimations will be inaccurate and not reflect the actual work.
For example, let’s look at a user story with a complexity of five-story points. Developers will exclude the testing effort done by other team members and estimate their relative work with three-story points. Furthermore, the team members responsible for the testing effort will evaluate it as a very low effort at one story point.
Both estimations are wrong because they reflect less work than the team needs to invest in delivering the story.
Estimation Made Without Calculating All Factors
When the team calculates the estimated work, they need to examine all factors involved in their sprint commitments; these factors should be well defined, as a checklist for the team to follow as part of their estimation process. Here is a sample checklist from one of my teams:
Are there any dependencies on other teams/external support?
Who are the people available to accomplish the task?
What is the experience and knowledge of those people?
Are there any known risks that can affect the timelines?
What is the development and testing strategy?
Managers Who Vote
Managers can vote only if they are part of the development team and actively participate in team activities throughout the sprint (e.g. coding, testing etc.). In any other case, managers should not be allowed to estimate as they do not participate in the execution process (remember the story of the chicken" and the pig?).
Managers Who Interfere with Team Estimations
During an estimation session, the team starts to estimate and find that there is pushback from the manager during every large estimation. The manager thinks that the estimation is wrong. Once this occurs, the team will never feel safe sharing their actual estimation. This results in smaller time estimates and deadlines being missed.
Estimating Small Stories
Is there a real need to estimate stories that take only one or two hours? No. Instead, the team can use an agreed time box for these specific stories without the entire estimation process.
Not Learning From Previous Mistakes
I’ve learned that no matter how good and experienced the team is, they can still fail to estimate correctly. This is fine; one cannot expect the team to succeed all the time. That said, I still expect the team to discuss issues and learn from them, so future estimations are more accurate.
Estimating Bugs That Are Part of the Sprint
There are two types of bugs that can be part of a sprint. The first is bugs that should be added to the sprint backlog because of technical debt, field requests, etc. These bugs can be part of the estimation process, and sometimes they are not.
The second type of bugs is related to coding and testing activities found during the sprint. These bugs should never be estimated, as they are part of the original estimation (The team should take bug potential as one of their estimation factors).
Conforming to the "Expert" on the Team
The process of relative estimation involves all team members. They are equal and can share their feedback as part of the estimation process. The problem begins when team members lack the confidence to provide their estimation and therefore conform to the opinion of a vital team member. If we want to build a cross-functional team, we must ensure each team member can contribute to the overall effort and share their feedback.
An excellent way to resolve this is for the expert in the team not to estimate and have the rest of the team estimate. Once they are all done, we can ask the expert to share her estimates with the rest of the team.
Averaging Story Points
This mistake is more relevant to new Agile teams who are unfamiliar with using story points. Assuming we have a team that needs to estimate a new user story during the planning meeting. Half of the team evaluates four-story points, and the other half two story points to complete. This often leads the team to take the average estimation (3 points) without discussing the gaps between the groups to provide an accurate estimate that reflects the actual work needed to implement the story.
Adjusting Estimates Without Communicating
The team had their planning session, gave estimates, and started the sprint. They start work on a story and suddenly realize that their original estimates were wrong (i.e. the solution envisioned is incorrect). The team adjusts the initial estimates based on the new information during the sprint without telling anyone.
This indicates significant problems within the team that you must understand before they have a more substantial impact on the team’s performance (e.g. fear within the team of being wrong, the estimation is not effective enough or is misused).
Re-Estimating Unfinished Stories
This scenario is prevalent among Agile teams. They start to work on a story, and at the end of the sprint, the story is incomplete, and they use the magic solution of moving it to the next sprint. The team has not fully completed the story, but they finished almost 50% of the work. Is there any need to re-estimate it?
The answer is no, as the estimate may not have been accurate, but this is not a real problem. In the next sprint, the team will have a story that includes all incomplete tasks and will allow the team to understand the exact time to complete the story. In addition, this story will not be part of team velocity in the original sprint, but rather it will be part of the calculation of the next sprint once completed.