Earlier in the week I introduced the idea of #NoEstimates, suggesting that estimates are not essential on technical projects and it could be possible to run projects without them. For example: early in my own career, I was assigned to a business unit for three months of work. The specific scope of work changed so often that instead of trying to do the original project, we split the work into index-card sized stories (at left), then had the customer order the cards. I met with the customer weekly, showed what was done, and allowed the customer to add new cards, change the priority, and, occasionally, tear them up.
Here’s the amazing thing: After two and a half months, the customer looked at what was left and agreed these things had low value. The project was done early!
Then again that was a single programmer for three months. Can #NoEstimates be done with multiple teams, on multiple projects? At the program and portfolio level? If so, how?
I believe the answers are “Yes”, “Yes”, “Yes”, and “Let’s Talk.”
“How do I decide if a project is 30 stories or 60 stories, Matt?”
There are two things going on here. Yes, on the one hand, the customer wants to know the price. The other, more subtle issue is that that project is not defined well. If it were, we’d have 45 stories!
So the question is really “how big is this amorphous blob that has yet to be defined?”
While the estimation is not essential, the part, the figuring-it-out part, is something we have to do.
So let’s take a day, conduct a story-mapping workshop, and figure out what we are actually building. After that, we can use historical comparison (to other projects of that size) or yesterday’s weather to figure out how long this project will take.
“Okay, I can live with that. This #NoEstimates stuff is fine for small projects, but what about issues of governance? I need to know if a project is between 10Million and 100Million dollars, and I need information to decide if we should fund it.”
Let’s assume we are talking about an ERP upgrade, or a CRM implementation here. This is not the kind of project where you can budget 10 million, manage scope, and ‘ship what you have.’ Instead, there are interfaces into the company’s HR system, and payroll, and LDAP, and other components. On any given Monday, you are ready to ‘go to production’ or not.
Projects of these size don’t do traditional estimating at the task level anyway.
I am serious. Remember our definition: Estimates are done by technical contributors.
This kind of project will be done by comparison to similar projects — bigger than the last ERP upgrade (6 months, $12 Million), smaller than the system conversion we did two years ago. (2 years, $30 Million). That gives us a range of time and money to deal with and answers the ostensible question.
Clueful management can come up with these sorts of estimates on their own. Clueless management, like the pointy-haired boss in Dilbert, will abuse and misuse the estimation process anyway.
The techniques I am talking about here, historical forecasting and spike prototypes are not bad governance …
They are better governance.
So how do you organize a 100, 200, 500+ person IT effort without estimates?
Still more to come.