Save Your Sprint! How to Avoid the Three Types of Bad Project Estimates

Unfortunately, too many Agile teams rely on estimation methods that obscure rather than reflect reality. And bad estimates create a hazardous blind spot that can easily compromise sprint success. By rethinking the way you make estimates, you can prevent team crippling blind spots with honest estimates that optimize sprint planning and execution.

First, let’s clarify what we mean by honest vs. dishonest schedules. Your schedule is probably lying to you if:

• It is fed with bad estimates
• It is unable to adapt to change

So, what makes an estimate bad? Bad estimates all have one thing in common: they don’t accurately reflect reality. And if you feed a sprint plan unreliable estimates, you get an unreliable schedule. As they say: garbage in, garbage out.

There are three kinds of bad estimates that are particularly bothersome because they are so widely used by development teams of all shapes and sizes.

Bad Estimate #1. Estimates Based on “Story Points”

Story points represent units of relative size that many Agile teams use to estimate software requirements. That story points are so widely used for estimating time in Agile development, is a bit of a mystery. Why? Because story points don’t translate to schedule time. In fact, they don’t have anything to do with the way real people even think about time. This means that teams have to establish their own translation guidelines for story points which thwarts efficiency and invites misinterpretation. It also makes it difficult to collaborate with stakeholders who don’t use or understand story points.

Bad Estimate #2. Blatantly Unrealistic Estimates

Development teams are under a lot of pressure from business owners who want to ship product as quickly as humanly (or not humanly) possible. To get business owners off their backs, developers tend to over-commit and enter overly optimistic (read: unrealistic) estimates. Unrealistic estimates create problems for everyone.

For starters, they create idealistic schedules that look good on paper but have little utility or relevance to reality. And, since an overly optimistic estimate provides a best-case-only scenario, there is nowhere to go when a delay creeps in, which means the whole schedule gets botched. Finally, the expectation of business owners that optimistic is better than realistic can stress the capacity of development teams to an unhealthy breaking point, which threatens both morale and product quality.

Bad Estimate #3. Estimates with Hidden Buffers

Adding a buffer to an estimate provides breathing room in the schedule. Often times, the one making the estimate doesn’t know how long a given task will take – especially if it’s a task they’ve never done before. Developers tend to like buffers; management does not.

The real problem is that a buffer is almost always hidden; no one really knows how big it is or what impact it has on the schedule. It is merely implied. Because of this grey zone, it is next to impossible to respect the buffer. And when the buffer is not acknowledged -- much less respected -- the schedule becomes compromised and iteration targets are easily missed. The bottom line is this: a bad estimate may be overly padded, arbitrarily defined, or unrealistically optimistic, but it is always a danger to your schedule.

There’s one more important point about bad estimates. And that is that they are conveyed in single points of time. This too jeopardizes sprint health. As we saw with the best-case-only scenario above, single-point estimates (such as four days, nine hours, or 13 story points) don’t have a built-in margin of uncertainty to account for the unknown. They are rigid fixed points, veiled in a cloud of obscurity; and they create rigid, unreliable schedules.

Why Tools Matter

So why is this such a big deal? Because rigid schedules are inherently anti-Agile. One reason Agile methodologies favor “individuals and interactions” over “processes and tools” is that traditional project management tools are too inflexible for Agile’s dynamic, collaborative approach. Unfortunately, too many Agile teams are unwittingly using tools that work against them by locking them into bad estimates and rigid schedules. Or, if they reject tools altogether, they are left without much of a schedule at all (and a white board that looks like this):

But a new generation of project management tools is emerging that allow teams to estimate their time in ranges rather than single points. Here’s how it works:

Use Estimates that Reflect the Way You Actually Work.

Give your time estimates in ranges of real time (i.e., 4-7 hours). Not only is this the way you really think about time and work, it has a buffer of uncertainty built right in for everyone to see. It sounds simple, but the impact is profound. With a ranged estimate you are giving a best-case (low end) and worst-case (high end) scenario of how long it will take you to complete the task. This range captures and conveys uncertainty; an estimate with a wide range, such as 2-5 days, conveys more uncertainty than a narrower estimate, such as 1-2 hours. As work progresses, the uncertainty narrows, and the schedule becomes an even more accurate reflection of reality.

Benefits of Using Ranged Estimates

• Let you plan accurately even within a large range of uncertainty
• Allow teams to drive uncertainty out of the schedule early (since it can be seen clearly)
• Prevent sandbagging; and
• Create a neutral, honest point of communication within teams and with business owners

Conclusion

Agile represents a move to more interactive, humanistic software development methods. While reliance on processes and tools is downplayed in favor of communication and collaboration, the demands placed on Agile teams requires more and better planning, estimation, and organization— not less. As such, Agile teams benefit from tools that appropriately support and enhance the way they work.

About the Author

Jason Carlson is the co-founder of LiquidPlanner, online project management software built on an innovative probabilistic scheduling system using Agile methodologies (20 sprints and counting!). Email him your questions at [email protected].