Estimation is Part of Scrum…and Mostly Irrelevant
In the past month, there has been a great deal of discussion around estimation. First, it began with Joshua Kerievsky and his article. Later, Tobias Mayer shared his perspective. I even heard recently that Mike Cohnis diminishing the importance of estimation. I think Ward Cunningham sums up my attitude with respect to estimation with this 2010 quote from twitter
“Estimating is the non-problem that know-nothings spent decades trying to solve.”
All this passionate talk about estimation, getting rid of estimation completely, estimating in hours vs. relative estimates and doing away with story points seems like a bit of a tempest in a teapot. I mean, who really cares if the Team estimates an item from the Product Backlog as 10 days of work or 13 days of work? The only time when people get serious about estimates is when the Team does not deliver anything of value after a long period of time, then someone important asks, “Where are the estimates for all this?” As if sifting through the detritus of some old, made-up numbers will allow us to fix blame on the appropriate party.
In addition, is it really possible at the level of granularity of a typical Product Backlog item, aka a user story, to tell the difference between 6 days of work and 7 days of work? Not really. But having more details up-front about the features is not going to help with a better estimate because the time spent to understand the details could be better spent just doing the work. Estimations are merely a tool to help the Team get into alignment around what is needed to deliver a feature and to ensure the Team is making a reasonable commitment. Estimates are just an educated guess on the effort, size or some other factor, based on the available (and incomplete) information provided at the time.
The size and accuracy of the estimation is completely irrelevant since a Team in Scrum does not make a commit to the estimates. All the estimation and task decomposition that occurs during Sprint Planning is to help the Team make a promise to deliver something of value that is neither too big nor too small.For me, the process of estimation helps facilitate that process.
When I coach teams in Scrum, I do a couple of things to make the whole process faster and more accurate. Most people are good at estimating small tasks, i.e. “this is what I am going to do today and this is what I am going to do tomorrow”, so we only use small tasks in Sprint Planning. With my Teams, there are no tasks that exceed 16 hours. If any task is identified greater than 16 hours, it is decomposed into smaller tasks. There are also no tasks smaller than 4 hours because to ask people to write down all the tiny little tasks is simply micromanagement and demonstrates a profound lack respect for highly-educated professionals. If you cannot trust people to manage their day in chunks of 4 hours or less, you got a problem with your staff or your management.
When I talk about estimates of Product Backlog items, we tend to shift away from the small, discrete estimates in time and move to abstract, high-level estimates. I prefer to use dimensionless units of time common with most relative estimation processes. I really don’t care if people use time, points, tee shirt sizes, Fibonacci numbers, gummy bears (which always seemed very silly to me) or whatever. Just pick a scale and stick with it.
It is true that while explaining relative estimating to clients, I would watch people struggle with the abstractness. When the question came, “What is a point?” I always told the people I worked with, “A point was about a day of work”. (For all you XPers out there, “points” are “units”)
After reading Josh’s article, I suppose I missed the “point” about not linking an abstract units of measurement to time, but estimates were never real measurements of time. Estimates were always a guess and were just approximations of time. To me, linking abstract measurements of time to real measurements of time (“about a day”) seemed to facilitate the process of estimating. Once you make the connection for people, I could see them relax and their conversations would focus on what was important – how big is this piece of work compared to that piece of work.
In my Certified ScrumMaster classes when I have to talk about estimates, which thankfully is not very often, I describe three factors which influence an estimate:
- Effort – how long will this work take? This would how much time a person spends with “hands on the keyboard”.
- Complexity – is this activity easy-to-understand with few moving parts or does it depend on other people and\or technologies? The more complex the activity, the longer the activity takes to complete.
- Risk – is this work something we have done before with a technology we are familiar with and we are interacting with people we know or is this completely new activity with a new\unproven technology with people we don’t know? The more unfamiliar we are with the activity, technology and\or people, the greater the risk and the harder it is to forecast an accurate estimate.
Estimation is not going to go away. Most businesses need some type of estimation to base their decisions regarding staffing and resource allocation. Since estimation is part of the Scrum framework, we need to ask the members of the Team for estimates if we claim to do Scrum. However, we do not have to make estimation a dreadful activity with a lot of stress. They are nothing more than guesses and if people want to believe they are more than that well…good luck with that.
