Estimating time is one of the most challenging aspects of Agile. To deliver quality products on time and according to scope not only requires a talented team but also a consistently clear view of the work effort and progress throughout the sprint.
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