We were in the fanciest board room I have had the pleasure to sit in. Two large TVs took up one wall with a Crestron unit inset to their right. The large and beautiful table had electronics wired into it as well, and it comfortably sat 15 people. I had a slideshow up on the TVs and was talking through portfolio management and forecasting when the vice president in attendance said, “But none of this matters. There’s no way to estimate accurately. It’s all just made up.”
I was stunned. I literally got a degree in the science of project management. Developments in estimating project complexity and size over the last forty years have resulted in reasonably accurate estimation that lets us predict delivery times well. But she didn’t know that.
And that’s fine. I let it pass, because in the moment it didn’t matter, and I can build estimation into their project later. For now, I want to share with you a few tips for how to estimate accurately.
But first, a magic trick
Here is the magical trick that all pros use when estimating.
They don’t do it themselves.
The truth is, humans really suck at estimating. We are so bad at estimating things like the amount of time a task will take, or how complex a piece of work is, or even how much something will cost over time. We have developed a lot of equations and mathematical principles that help us estimate certain things, but outside of material sciences, it’s really hard to do.
So what is the trick? We do it as a group. Strangely enough, while an individual human is really bad at estimating, a group of humans to can do a pretty accurate job. There is a really interesting experiment/site called UNU that gets groups of humans to estimate things, and then spits out the results. From a recent Reddit post,
TechRepublic challenged me to predict the Kentucky Derby (http://www.techrepublic.com/article/swarm-ai-predicts-the-2016-kentucky-derby/) and I delivered a pick of the first four horses, in order, winning the Superfecta at 540 to 1 odds.
In a little bit, I’ll talk about planning poker and how it can help us estimate things as a group, but first let’s talk about two different inputs for estimation.
Some organizations use bottom-up estimation. This is where you get the people in the field, or on the factory floor, to do the job at estimating how long something will take or how much it will cost. Because these are the people actually doing the work, the theory goes that they know best how long something will take. And generally speaking, these people do. They’re going to know more about the work at hand than anybody else, and their experience doing that work is going to help them provide a more accurate estimate of how long something will take.
The problem that some organizations run into when they rely on bottom-up estimation, however, is that the regular workers are typically focused on their day-to-day work. They know what’s going on today, and maybe next week, but it will be difficult for them to take into account other things going on in the organization.
Top-down estimation is typically done by somebody in charge, be it an executive or a project manager. This type of estimation can be effective because the people at the top have a better view of everything the organization is doing. While the line workers may not know if there’s a big project on the horizon, or that a bunch of people will be taking vacation next month, or that there is an additional project that’s going to take people away from some teams, the executives and managers can keep these things in mind when creating estimates.
While this has the potential to be more accurate, in my experience the executives often develop a far less accurate estimate simply because they are trying to estimate on behalf of other people. Whenever we aren’t doing the work ourselves, we are even worse at estimating how hard something will be, or how long it will take, and this is especially prevalent in top-down estimation.
So if the line workers can’t provide a very accurate estimate because they don’t have all the information, and the executives cannot provide a very accurate estimate because they don’t know everything the line workers know, what do we do?
Our best course of action is to follow the Scrum principle, “Take it to the team.”
The biggest weakness of estimation in many organizations is that it is done in a vacuum. Yes, it is important to have input from our line workers, but your line workers can’t take all of the factors within the business into account. Similarly, if only executives or project managers are providing estimates, there may be factors about which they are unaware. We need to gather information from throughout the organization, and talk about the work that we are doing as we estimate it.
One method of estimating work as a team is to use a very simple device called planning poker.
You can find a lot of resources online about planning poker, from sites that facilitate virtual planning, to books that will help give you additional insight. But it’s really quite simple, so I will outline it here and leave it to you to find more information if you feel the need.
In planning poker, we get several decks of cards and distribute them to the people who will be doing the estimation. You can buy special planning poker decks, and I find these helpful because they’re already set up correctly.
A bit of work needs to be done before we play planning poker–in particular we need to know what it is we’re going to do. This is where having a work breakdown structure can be helpful. Once our work is broken down, we’re ready to estimate each of the tasks involved.
We want to make sure that the team doing the estimation is made up of a wide range of people, but not too many people. The typical Scrum team is recommended to be seven people +/- 2, and 5 to 9 people can result in a decent estimation. Ideally, this estimation should be done by the people who are doing the work, similar to the bottom-up approach of estimating. But the team should also have input from other people in the organization, such as a project manager, Scrum Master, or other person who can provide the top-down view. This way, the team has all the information they need to inform their estimate.
Next, the team will discuss a particular task from the work breakdown structure, and then secretly select a card that communicates the complexity of this. This is done in secret so people’s estimates are not influenced by others in the group. In typical planning poker, the cards have numbers on them that increase to the Fibonacci sequence. A fairly simple task might be a one or two, while a task that’s almost impossible to comprehend might be a 100. When we come across things that are higher number, that helps us to understand that we need to break that task down further so we can better estimate.
When you get a wide gap in the estimate (say somebody selected a 3 and someone else selected a 21), you have a discussion about why one person thought this task would be simple and why the other person thought it would be hard and/or time consuming. Everyone has different information that informs their estimate, so after a short discussion, you play again and re-estimate. Once the team reaches consensus on a task, you have your estimate.
In agile, we will use epics and stories instead of a work breakdown structure. For the purposes of estimation, it doesn’t really matter which you use, so long as you break things down far enough that people can wrap their heads around the tasks and provide an accurate estimate.
It is possible to accurately estimate tasks as an individual, but this only works well under particular circumstances. These circumstances are:
- You are doing the work yourself, and not estimating on behalf of other people.
- You have performed the task before, and noted how long it took you.
One of my favorite principles of Scrum is that estimation is based on empiricism. We can’t just pull numbers out of the air, but instead we build estimates based on what we have observed in the past. We know how long something will take because we know how long it took.
To be honest, the same happens with teams that are estimating. The first few times they estimate, they are likely to make mistakes. They will over and underestimate, over and under commit, and generally be fairly inaccurate. But that’s okay, as long as we learn from our mistakes, and typically we observe that Scrum teams become better at estimating after 3 to 5 sprints. No one is very good at something the very first time they try it, and estimation is no different. But if we practice and stay consistent, and get all of the right information in advance, then we can estimate accurately in a (somewhat) scientific and reproducible manner.