5 Overlooked Opportunities in Agile Estimation

Jonas Salk once said, “The reward for work well done is the opportunity to do more.” The same holds true for the process of agile estimation.

The targeted outcome is a velocity that allows the development team to determine its pace and enables the product owner to make some reasonable prediction for the release. But the process also offers other opportunities that are no less valuable. Here are five additional chances to further improve your work that your team may be overlooking.

The Opportunity to Learn from Others

During the estimation process, the team may get involved in course correction beyond their skill sets. Different members of the team come forward to defend their story estimates, challenging assumptions made by the other team members and proposing other suggestions as they see fit.

For example, a developer may indicate that a story deserves five story points because it requires good analysis up front by the business analyst on a certain flow. The business analyst who estimated it at three story points then thinks, “Yeah, there is more for me to do than I thought,” so then they agree with five story points.

The tester who estimated the story on the lower side then asks for an explanation, and the business analyst explains that the story would require extensive testing coverage for the small yet complex change in it.

The benefits that the team derives here are the valuable input from all the team members, the chance to learn more about what your coworkers do and how they think, and the ability to collaborate in order to develop the building blocks of the ultimate solution.

The Opportunity to Identify Alternatives

“How about,” “what if,” and “why” are all types of questions that help us understand the estimates our other team members make, opening the door for alternate approaches to a solution.

Let’s say one of the developers rates the story at eight story points, citing that it would require development of four different APIs to populate two of the grids on the screen. The other developer challenges him: “But I think just two APIs could do with some optimized logic, so the estimate should be lower.”

Likewise, a tester may estimate a story with an assumption that the third-party test environment will be up and running during the testing. But the rest of the team suggests, “How about keeping a provision to mock the services in case the environment is not operational? Let’s keep the estimate on the higher side.” 

The benefit comes in the form of a handful of solution approaches available to the team, enabling them to agree on the most appropriate one.

The Opportunity to Validate the Story

Once the product owner explains the story, the team estimates it with the available information. This is where it is validated based on certain criteria:

• If a story is estimated on the very high side because of the amount of work it carries, it can’t be delivered in a single sprint—for instance, if several services need to be modified or added on multiple layers of the application to receive a new value from an application or interface
• If gray areas are identified on technical and functional fronts, then these need to be addressed first to appropriately estimate the story—such as if visual designs are not clear, multiple versions of the Web Services Description Language exist, or the interface is a black box for the team

The first criterion would demand that the story is logically split into eligible pieces for the sprint. The second criterion wouldn’t allow the story to proceed further unless the gray areas are addressed; otherwise, it will return to the backlog.

Here, the benefit comes in terms of ensuring that the stories are sliced enough to deliver in the time available and have sufficient details to be workable backlog items.

The Opportunity to Improve Teammates’ Estimating Ability

Everyone on the team must share the opinion for the agreed-upon estimate for a story. There will be outliers, and the person raising the objection has to explain their reasoning to others in order to develop a consensus. If the person is always inconsistent and is unable to explain their stand, it could be due to several reasons:

• Their knowledge and experience are not on par with the rest of the team
• They’re not able to understand and adjust with the agile estimation process
• They’re unable to concentrate due to personal or professional issues
• They’re a poor performer or don’t fit in on the team

The ScrumMaster should work with the person to help understand the problem area through trainings, skill upgrades, and counseling. The team may also strategically pair this person with someone more experienced to help the person see why the rest of the team thinks the way they do.

The benefit comes in terms of protecting the spirit and rhythm of the team by keeping competent individuals on the team and identifying those that need to grow.

 The Opportunity to Reinforce Scrum Values

The five Scrum values of courage, commitment, focus, openness, and respect all should be exercised by the team during the estimation process.

With a focus on estimating stories, team members express their opinions on the story points and show courage to challenge each other on disagreements. The team finalizes the estimation by having rounds of discussions, demonstrating mutual respect for each other’s views and commitment to decide on the best course of action.

The benefit is a strengthened team and Scrum framework.

Agile story estimation gives the team insight into the level of effort for each work item, allows the team to assess each requirement’s relative priority, and lets the team refine and clarify story items. But there are even more benefits that can be gained from the estimation process. Try to take advantage of these five opportunities for growth when your team is estimating stories.