Do You Make These 7 Agile Estimation Mistakes?

A number of conceptual challenges can come up for teams when estimating stories. Sometimes these can lead to confusion about how agile works, and whether its actually delivering on what it promises.

Being aware of these pitfalls, and having a clear answer to the questions they raise, can help keep the team on-track and keep observers from feeling disconnected.

1. Measuring Productivity by Points

Among the most common issues that cause confusion when explaining agile estimation is the idea that the points of effort associated with a story represent the value of that story, either in terms of business value, or in terms of objective team productivity. That kind of misunderstanding can get in the way of effective estimating.

A team cannot be compared with another by matching the points they have completed or their average velocity any more than they could be compared by looking at the size of their monitors.

Comparing agile teams on points completed or average velocity is like comparing them on average monitor size.

While points are a valuable metric internally for team members to consider the effort needed to get the work done, they are only relevant relative to the team’s previous work experience with stories that they have estimated to require a similar amount of effort.

The points associated with a story are abstract. They differ from team to team, and shift over time as a team gets better at understanding its own productive capacity. The only intrinsic value of points is their ability to help the team get better at predicting how much work they can realistically get done in the next sprint.

2. Equating Points With Hours or Days

On teams unfamiliar with how points work, team members may default to assigning point values to stories based on the number of hours they believe a story will take to complete. When a team is just starting out, this approach may help get the ball rolling. However it is problematic if the team doesn’t quickly shift its perspective on points from an absolute hourly scale to a relative one.

Points for a team are a subjective way of measuring the effort involved in completing one story based on the effort that it took to complete a prior one.

As soon as an hourly scale fails to match the actual effort of the first story, the ability of the team to use hours as a metric for effort is destroyed. After all, the eight actual hours spent completing a story that was originally estimated to take five predicted “hours” cannot be compared to the 13 hours being estimated for completing the next story.

The sooner the team understands that points are a relative metric, and not an absolute value, the easier it will be for them to start estimating stories based on their actual capabilities.

It is only after several sprints that a team begins to recognize its velocity, or the average number of story points it can complete in a single sprint.

One team’s velocity has nothing to do with another team’s, and neither should its point estimates. Real points for a team are only relevant within the team itself.

3. Estimating Like Heroes

I’ve worked on teams where the team members had come from an environment that rewarded superhuman effort. Often team members tried to demonstrate their competence by estimating that a story would take less effort, and therefore fewer points, than was reasonable. As a result, the team either had to scramble to complete the stories in the backlog or fail to meet its goals.

In cases like this, it’s important to remind everybody that they’re estimating the effort needed for anyone on the team to complete the story, not proving how quickly they themselves could complete it.

Hero culture is hard to reconcile with agile processes, but many companies are used to rewarding their engineers based on how well they conform to unrealistic expectations of sustained high performance.

Hero culture is hard to reconcile with agile processes, but many companies are used to rewarding their engineers based on how well they conform to unrealistic expectations of sustained high performance.

Adopting an agile approach will expose these tendencies in any organization, and will help replace it with realistic, sustainable and productive teamwork between engineering and the rest of the company.

To keep team members from assigning estimates based on their own desire to demonstrate their skill, remind people frequently that the estimate should reflect how difficult a story would be regardless of who completed it on the team.

4. Confusing Points and Business Value

It’s also very important to distinguish business value from effort.

While an engineering team may be qualified to estimate the amount of effort involved in completing a story, only the product owner can weigh all the variables and effectively estimate the business value of a given story.

In addition, business value can change frequently, based on a wide range of factors, including the order in which stories are completed. Business value can even change during the course of a sprint while the team is busy working on a project.

Product owners may choose to consider the ratio of business value to estimated points of effort as a way to help prioritize the backlog. It can also be motivational to let the team know just how much business value a particular story carries for the company at any point in time.

But an organization that wants to stay agile knows that business value can shift as quickly as the market changes. Often engineers can be distracted from the kind of deep attention necessary to get their work done if they are too close to the turbulent and irrational factors that play into estimating business value.

Keep the concepts of business value and points of effort separate to maintain a productive workflow, and allow the team to estimate the effort involved in completing a story accurately, independent of how much value the product owner may place on the results.

5. Adjusting Point Values

The iterative nature of agile is one of the key advantages it offers. When a team has misestimated a story as either too large or too small, there may be a tendency to want to change the estimate as soon as more information comes in. It’s a natural impulse, especially when a team has adopted agile because it wants to be more nimble and flexible. But this can undermine the effectiveness of the point system.

The points associated with a story are there as a reminder of how accurately the team took the story and matched it against their shared experience and knowledge to estimate how much effort it would take to complete. When there is a discrepancy between the actual effort involved and the estimated effort, the team gets a chance to learn from practical gut-level experience just what points mean–and how to estimate them in the future.

When there is a discrepancy between the actual effort involved and the estimated effort, the team gets a chance to learn from practical gut-level experience just what points mean–and how to estimate them in the future.

Noticing that a story is taking much more or less effort than the team had originally estimated is worthwhile, but altering history by changing the estimate erases the real value of points, which is the invaluable opportunity to get better at predicting for the next set of stories. The time to consider adjusting estimates is at the next sprint planning meeting, when a similar story comes up and needs to be estimated.

6. Blindly Following Points

But preserving point estimates doesn’t mean acting like robots during a sprint when a story isn’t conforming to the estimates.

I remember one team I worked on that had estimated a story might be fairly straightforward, largely because they knew there was a standard library available to do most of the heavy lifting. Completing the story was just a matter of integrating the library, the team thought.

But the story’s acceptance criteria went beyond the abilities of this library. The team realized quickly that they had to develop custom low-level routines to complete the story. Soon, work on this ballooning story started to sap the team’s productivity and threatened to put the other stories in the same sprint behind schedule.

Fortunately, this team had attentive product owners who were actively attending the daily standups and who noticed this trend in time. There were other stories which they had originally considered lower priority based on the ratio of their business value to the points of effort they would require. But that ratio was altered by the unexpectedly high effort required for this particular story.

By adjusting the backlog priorities to account for the actual effort needed to complete this story, the product owners were able to work with the team to shift focus toward stories with a higher business value ratio.

At no point was the estimate for the existing story changed–that would mean rewriting history–but the team was able to shift focus toward other stories and remain productive.

7. Failing to Learn

Agile approaches always include the concept of a retrospective, in which the team can get together and discuss how the sprint went, including what went well and what didn’t.

This is an excellent time to bring up stories that seemed to the team like archetypal examples of a certain point estimate, and which therefore might be useful as reference points in the future. It is also the time to discuss stories that were widely overestimated or underestimated.

I’ve never been on a team that hasn’t encountered at least one story that they overestimated by a huge margin.

One team learned for the first time at the sprint planning meeting about a story that involved a completely unfamiliar technology and therefore estimated it with too little understanding. After they started researching the story during the sprint, they quickly discovered that the solution was not only simple, but had already been done for them. All they had to do was wire it into the code.

Part of the estimation and story development process involves keeping the team aware of what the product owner is planning, so that nobody is blindsided at a sprint planning meeting with a concept they have no idea how to execute on.

A good product owner will be transparent about discussing future plans with the team during the sprint, and a responsible team will make sure to ask questions and come to a sprint planning meeting prepared to give realistic and well-considered estimates for new stories.

Beware Old Habits

When a team has a history of working together well in an agile manner, everybody has the opportunity to demonstrate their value and participate actively. But when a team is just starting out with agile methodologies, old habits can interfere with the estimation process.

Pay attention to these pitfalls, and you can help your team learn to estimate in an agile way.

Frequently Asked Questions on Agile Estimation Mistakes