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.
1
Print this article
Email this article
Talk Back!
Write to Editor
