Updated: May 20
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 bad patterns often seen in Agile teams related to their estimation process. if you identify one of the items below in your own process, make the necessary adjustments to mitigate it.
Partial Vs Whole Estimations
Prior to 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 will not reflect the real work.
As an 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 who are responsible for the testing effort will estimate it as a very low effort at one story point.
Both estimations are wrong because they reflect less work than the team really needs to invest to deliver 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 form 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 take an active part in team activities throughout the sprint (e.g. coding, testing etc.). In any other case, managers should not be allowed to estimate as they not take an active part 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 during every large estimation that there is push back from the manager. The manager thinks that the estimation is wrong. Once this occurs, the team will never feel safe to share their real 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 need for the entire estimation process.
Not Learning From Previous Mistakes
One thing I’ve learned is that no matter how good and experienced the team, 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 them to discuss issues and try to 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 request, etc. These bugs can be part of the estimation process and sometimes they are not.
The second type of bugs are 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 own feedback as part of the estimation process. The problem begins when team members lack the confidence to provide their own estimation and therefore conforms to the opinion of a strong 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 own feedback.
A good 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 own estimates and with the rest of the team.
Averaging Story Points
This mistake is more relevant to new Agile teams who are not familiar with how to use story points. Assuming we have a team that needs to estimate a new user story during the planning meeting. Half of the team estimates 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 so that they can provide a true estimation that reflects the real work needed to implement the story.
Adjusting Estimates Without Communicating
The team had their planning session, estimates were given, and the team starts 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 original estimates during the sprint based on the new information they now have, without telling anyone.
This indicates major problems within the team that you must understand before they have a bigger impact on the team’s ability to perform (e.g. fear within the team of being wrong, the estimation is not effective enough or is used incorrectly).
Re-Estimating Unfinished Stories
This scenario is very common among Agile teams. They start to work on a story and at the end of the sprint, the story is incomplete and they just use the magic solution of moving it to the next sprint. Now, the story is not fully completed by the team, 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.