Are software estimations useful? I say yes, but perhaps not for the reason you might expect. To me the principal value of estimating is the discussion among the team members that takes place when they try to agree on a size. Honestly, I am less interested in the size estimate than I am the shared clarity that results from a thoughtful and at times vigorous debate among the people who actually will do the work.
No Estimates Camp
I have numerous informed and thoughtful colleagues who are more aligned with the no-estimation (#NoEstimates) camp. These folks believe that estimates are frequently not practical, and can at times be down right dangerous. I understand some of their concerns, but I think at times they might risk throwing out the baby (the value in the discussion) with the bathwater (their desire to eliminate estimates).
What adds to the confusion is that the word “estimate” can imply different concepts and multiple levels of abstraction. Are we estimating the size of an item or when the development effort (project) will complete?
Completion Date Estimates
Let’s start with the estimation of a completion date. The mountain of data certainly supports the conclusion that our industry (software development) is not good at reliably predicting when something will finish. This is one of the reasons that in agile projects, the preferred approach to development is to work to a fixed date, with variable scope. In other words, the completion date can be predicted with 100% accuracy, but the scope cannot. I argue this is the appropriate tradeoff to make (when you can). You can read more about why this approach is preferred in my blog: Scope is the Antifragile Degree of Freedom.
At times, however, the date will not be fixed, so the question might still remain, “When can you get all of this stuff done?” To answer this question, you would have to have some idea of how much stuff there is (requiring size estimates) and some idea of the rate that the people doing work get things done (velocity). You can read more about this in Chapter 18 of Essential Scrum.
Size Estimates
Most of the time when I encounter people who are advocating no estimation, they are referring to size estimates (or magnitude or bigness estimates). As illustrated in the following picture, there are at least three different levels at which such size estimates might be applied: portfolio backlog items, product backlog items, and sprint backlog tasks.
As shown in the picture, each of these item types can be sized with different units and at different points in time.
Portfolio Backlog Item Estimates
Portfolio items are typically entire products or projects (or individual releases on their respective roadmaps). Usually a size estimate at this level is intended to communicate cost, and the cost number is used as part of an economic filter to determine whether or not the product or project is worth doing.
From this perspective, estimating portfolio-level items isn’t a matter of trying to predict when the product or project will be finished, but rather a rough order of magnitude of its size. The date something might finish is only partly related to its size.
I have seen companies be reasonably successful using rough, relative-size estimates like T-shirt sizes (such as small, medium, large, extra large, and so on). These companies typically associate a dollar-cost range with each T-shirt size. For more details, see Chapter 16 of Essential Scrum.
It is important to realize that a T-shirt approach to portfolio backlog item size estimating works better in an organization that has done many products or projects because there are enough examples and data points for an approximate size to be meaningful. A newly proposed product or project will be similar (in size) to one or more already completed products or projects. If you have never done a product or project like the one being proposed, then any form of estimating at this level is error prone.
Product Backlog Item Size Estimates
A great deal of the controversy I see over whether to estimate or not is focused on product backlog item (e.g., user story) size estimates. Teams that estimate these items typically use an approach like Planning Poker or ideal day size estimation to put numbers on items.
When used with a team’s velocity, these numbers can be used for release planning purposes (e.g., there are about 200 points of work in the upcoming release, and the team is able to complete about 20 points of work per sprint, so the team should complete the work in about 10 sprints).
There are some experienced practitioners who don’t believe that you can or should try to put size estimates on product backlog items. They propose that when it comes to product backlog item (PBI) size estimates, if you just create all of your items to be small and roughly the same size then you wouldn’t have to put size estimates on items. Instead, you could simply count the number of items completed in a sprint to determine velocity.
This approach sounds quite reasonable and I don’t doubt there are some teams who can do this. But let’s analyze the approach.
- This approach still does estimation, otherwise how would we know if the small items are roughly the same “size?” So, it’s a bit disingenuous to say this is a no-estimation approach.
- Not all PBIs will be at the same size at the same time (assuming we follow the principle of progressively refining larger items into smaller items at the last responsible moment), so there will be some larger PBIs in the backlog even if we do have a collection of smaller, similarly sized items toward the top (see Chapter 5 of Essential Scrum for a more detailed discussion).
- It can take some time for teams to acquire the skills to break down PBIs to be roughly the same size.
- Teams might have to split PBIs at unnatural points to achieve the same-size goal.
- Finally, and most importantly, one of the primary values of estimation is the learning that happens during the estimation conversations. Nothing promotes a healthy debate like asking people to put a number on something, which will immediately surface any disagreements and force assumptions to be exposed. If we were to do away with estimation, we would need to substitute an equally effective way of promoting these healthy discussions.
To re-emphasize my point, the act of putting size estimates on these items is one the best ways I have seen to promote a healthy discussion among the team members to achieve shared clarity regarding the item. In my experience, the act of estimating is how teams get items into the ready state. For more on the definition of ready, see my blog: “Definition of Ready.”
Sprint Backlog
Finally, there is the controversy of whether teams should put size estimates (e.g., ideal hours) on tasks in the sprint backlog. Actually the controversy extends to whether there should even be tasks. There are agile practitioners that believe that tasks are unnecessary and even unhelpful. Following the earlier example, if all product backlog items are sufficiently small, then each item would only require one or a few tasks to complete and therefore there is no compelling reason to waste time creating tasks.
I would agree that if your product backlog items were sufficiently small to require only a one or a few tasks then breaking PBIs into tasks wouldn’t add any incremental value.
Even among those who might be willing to create tasks there could be an aversion to sizing those tasks. The principal argument against it is, “Why waste the effort to size something when we wouldn’t get any value from the estimate? We’ll just do the necessary work and it will take as long as it takes—a size estimate will not change that fact.”
I fully admit there are agile teams that do not employ tasks or task estimates and they seem to get the job done. And, taking the view of the product owner for a moment, I would not care one way or the other as to whether the development team created and/or sized tasks. Tasks are clearly in the purview of the development teams; they provide no value to the product owner.
However, switching to my development team hat, as a technical person (all of my degrees are in computer science) I find tasks an important element for acquiring sufficient confidence for making a good commitment at sprint planning and for helping track progress during a sprint. So I, and many of the teams that I work with, find them quite useful. You can read more about this perspective in my blog, “Sprint Backlog – An Artifact for Acquiring Confidence.”
Conclusion
Most teams that I encounter do one or more forms of size estimation and find that they do get value from it. Other thoughtful agile practitioners put forward sound arguments for why estimating is not only valueless, but also at times harmful. Although I often agree with one or more specific points advocated by the No Estimation camp, I still see too much value in doing portfolio level estimates (with T-shirt size), product backlog size estimates (using relative size estimates like story points), and task level estimates using effort hours to advocate abandoning estimation altogether.
The good news it that agile approaches like Scrum are basically silent on whether you should or should not do estimates. So, like any organization that successfully applies agile, you should customize the approaches that work best for you. If you’re not sure, draw a reasonable line in the sand with regards to estimating, and then inspect-and-adapt (see my blog post “Why Be Perfect Up Front When You Can Be Agile”).