Enhancing Estimation Practices in Agile Teams

The Surprising Cost of Bad Estimates - Mike Cohn

Bad plans lead to many well-known problems. Teams deliver later than expected. Or the budget is blown by adding people in the hope that will help.

Sometimes a deadline is met but by dropping important features. Or the deadline is met by team members working overtime, causing burnout, frustration, and usually introducing bugs.

Inaccurate plans frustrate both team members and stakeholders.

But one of the worst, and perhaps most overlooked, impacts of a poor project plan is that the team loses credibility with its stakeholders.

As an example of how poor planning affects credibility, I’ve got a friend whom I’ll occasionally meet for lunch. He’s always 5 to 10 minutes late. If he emails me today and suggests meeting at noon, I’m going to arrive 5 minutes late myself.

I no longer trust him to be on time. His plans just aren't reliable. And that's OK because it’s just lunch.

But the credibility gap caused by unreliable plans is much worse on projects.

Consider a team that is either consistently late or always has to drop scope to meet a deadline. The project stakeholders ask this team if they can deliver a new project in 3 months. Team members think about it and decide they can’t deliver it in 3 months, but could do it in 4 months.

When the team members tell the stakeholders they need an extra month, the stakeholders don’t believe them. Why should they? The team has been consistently wrong on all prior projects.

At this point, stakeholders may tell the team to do it in 3 months anyway. And why not?

If a team never meets its stated deadlines, stakeholders may reason that they’ll stick with the 3-month deadline to apply some pressure, which has limited effectiveness. (And like me with my friend, they might also quietly expect it to be done later, in perhaps 4 months.)

Here's the bottom line: stakeholders will not treat a team as an equal partner if the team consistently provides bad plans and inaccurate estimates. Credibility is such an important factor that I include it as the first of four reasons agile teams estimate product backlog items in the first place!

Consider how things may have played out differently if the team instead had established a track record of providing decent plans. Note I said decent. Plans don't have to be perfect to be reliable.

When a consistently decent team tells stakeholders a project will take an extra month, stakeholders are likely to engage in a conversation about options to meet the desired, earlier deadline:

• Would it help to enlarge the team?
• Is there a feature or two that could be dropped or deferred?
• Would it help if team members were allowed to focus solely on this product instead of also supporting some old product?

When a team has a track record of presenting reasonably accurate plans, they will be treated as equal partners by the rest of the organization.

Many teams try to solve the problem of inaccurate plans by padding their next plans. This usually makes things worse as the team now has two things to estimate:

• The plan, and
• How much to pad the plan

When stakeholders call the team on padding the plan, the padding is often removed unless team members can present solid logic and evidence for the size of the padding.

A better solution would be for team members to assess why their plans have consistently been wrong.

Sometimes the problem is due to poor agile estimation. If that’s the case, there are many things team members can do to improve estimates of story size.

I’ll share just one technique now that's especially helpful for teams who chronically underestimate the amount of work involved in a particular product backlog item. It’s called unpacking.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/