I’ve been thinking about estimation these days. After the healthcare.gov site fiasco, and all the schedule games–many of which are estimation problems, I thought about why we estimate.
The larger the effort, the more we need to estimate. And, the more your estimate will be wrong. The more we estimate, the more we have schedule games. The smaller your effort, the easier it is to estimate.
That’s why I suggested you use agile approaches in this estimation series. You can break things down, and iterate. You get more information, and estimate smaller chunks. You are more likely to have accurate estimates.
Software is Not Construction; Software is Learning
Here’s one problem I have with estimation. Software is not construction. We can’t build software the same way we construct or manufacture anything. Software is all about learning as a team. We can timebox our learning. We can choose to stop doing something. We can put acceptance or release criteria around it and say, “We have done enough for now.”
But, we cannot say, “We can build this software for $xx per square foot.” We don’t know how to do that. Because we have not built exactly this software before. If we had built software like this before, we can estimate pretty darn close, because we either have historical data with good estimation quality, or we have small chunks of work we know about, or both.
When we estimate, other people think of our estimates the way they think of estimates in other fields, especially construction. Especially if you provide a single-point estimate. Even if you provide assumptions, which no one hears.
We estimate for these reasons:
- To provide an order-of-magnitude size/cost/date about the project, so we have a rough idea of the size/cost/date for planning purposes. An order-of-magnitude size means we want to invest just enough time in the estimate that we believe in the accuracy of it for planning purposes.
- We want to know when we will be done, because we are close.
- We need to allocate money or teams of people for some amount of time.
- Someone wants to know who to blame.
There is an alternative to estimating
Remember I said software is about learning? And, remember I said we never (okay, almost never) do the same software project twice?
Here’s something you can do. Make your features really small. Swarm (or as Woody Zuill says, mob) over every story every day. Always finish one or more stories every day.
If you always have deliverable software—this includes all tests, documentation, everything you need—you don’t need to estimate anything. You also gain the benefit of learning, so if someone asks, “How hard is thing to do?” the entire team can huddle together for a few minutes and say, “It’s this story and that story and this story, too.”
They then say, “We know it’s at least these three stories, and that’s off the top of our heads. Are those stories more important the ones at the top of our queue?”
What Do You Do? (Or, Prove It, JR!)
I don’t estimate my work. I work in chunks of work that take anywhere from 5 minutes to one hour. I rarely work in one-hour chunks. Most of my work takes less time than that. I doubled my output this year by moving to smaller chunks of work.
I finished one book this year, and have another in beta. I have more books in progress. All while maintaining the same number of speaking and training engagements. I wrote roughly the same number of blog posts. I edited more agileconnection.com articles. Why can I do more?
Because my tasks are small. Because they are small I don’t have to estimate. I don’t have estimation time built into my work. I work in flow. That changes everything. I rank what’s most valuable at any time, and work on that.
Why Do You Estimate?
Why do you estimate? If you’ve estimated because you always have, think about it. If you estimate because your money people want to do once-a-year money allocation, well, you know that’s fiction. You can do it without detailed project estimation.
For money allocation, decide how valuable the project is to you. When does the project have to deliver the value? Now, tell the project team when the value has to be delivered. That’s all.
Remember, you hired these people because they were smart, responsible human beings. Stop with the phases and all that nonsense. Tell them what you want. Remember, the phases exist because management wanted to be able to cancel the project before it got too far along. You were supposed to show a deliverable and re-estimate at each phase. If don’t cancel, deliver, and re-estimate at each phase, your phases are not working for you.
Buy them a copy of Manage It! Your Guide to Modern, Pragmatic Project Management, which explains how to manage projects in any lifecycle. Give them a ranked backlog. Let them deliver. If they can’t deliver in the money or date frame, they will tell you. They are responsible humans.
If you need an order-of-magnitude estimation, fine. That doesn’t take days to determine. That takes hours. It will be precise-wrong and order-of-magnitude-right. Timebox it. It’s an order of magnitude. Don’t hold anyone to that estimate. (Quick, what’s the definition of estimate? “Guess.” That’s the definition. I kid you not.)
If you want to know when you’ll be done because you think you’re close to the end of the project, ask yourself this question: Is it worth the time to estimate vs. the time to finish? It might be. But know you are taking time away from finishing.
And, if you want to play the blame game remember that management is the one who needs to shoulder the most blame. Why? Because management set the constraints. Don’t believe me? Read the estimation series now.
I can sympathize with management’s need for estimates. I like order-of-magnitude estimates for many things. I even like specific estimates as we get closer. But creating software is not like driving someplace or like constructing a building. When I drive somewhere, I do want step-by-step instructions. When constructing a building, I do want an estimate. And even then, I am pretty sure the estimate is optimistic.
When creating software, I want to see working software as we create it, because with software, we learn. The learning is what’s most important. Because once we’ve learned enough, we can stop. That’s what’s most valuable. Not the estimate.
