How Agile Teams Can Deal with Estimation
Agile teams often struggle with estimation. As essential as the concepts of measurement and feedback are to agile software development, the concept of "estimation" seems to stir memories of non-agile projects, and it provokes fears of excessive process.
Ron Jeffries explains that estimation is evil. Jeffries's point is that estimates are inherently inaccurate, but once they exist they often take on a life of their own, and that time spent understanding and addressing errors in estimation slows teams down and stops them from gaining all that they can from agile.
Jeffries suggests two approaches to avoid estimation. The less ideal approach in his view is picking an end date and delivering something every week, picking a limited number of features to deliver each week. His preferred approach is not to estimate at all. As Jeffries says, "Take a real product visionary as a product owner, and have them sit with a few developers for a week or two to build something."
Phillip Armour responds to Jeffries and takes the position that estimation is not evil. He addresses Jeffries's concerns about the risks of estimation by making a distinction between estimation and commitment. He defines commitment by saying that "The commitment is the estimate PLUS a calculated reserve needed to pay for the risk inherent in the situation."
Armour explains that "We do not need an accurate estimate as much as we need an accurate commitment."
Given these two views, how do you decide if and how to estimate? Martin Fowler explains the diffference between estimation that is useful, and estimation that is wasteful. Fowler states that "estimation is valuable when it helps you make a significant decision."
In my experience, planning poker-style estimation during sprint planning meetings can quickly indicate whether there is a common understanding of the problem and a potential solution. You can spend your time understanding the stories that have a wide range of estimates and spend less meeting time on stories that everyone already has a common understanding of.
Similarly, if a story has a higher estimate than the product owner expected, the product owner can reprioritize, or the team can discuss simpler approaches that solve the most important problem.
How much and when to estimate are not easy problems. Agile practitioners generally agree that spending a lot of time on estimating things that you plan to do far in the future isn't useful. If you are working in sprints or iterations, estimating a sprint seems like a useful way to measure velocity and make a reasonable commitment to a sprint goal. The key seems to be making sure that all stakeholders understand the value of the estimate—that the important thing isn't that the team met the estimates but rather that what the team delivered added business value.
How do you estimate? Does estimation help your team or hold you back? Can you work in timeboxed iterations without estimating?
