How to Move Beyond Project Estimates and Provide Better Value

The buzz in the room at Agile2013 Nashville is "no estimates" - the idea of dropping estimates entirely from the software development process.

Matt Barcomb, co-chair of the "Open Jam" stage, a management consultant and now vice president of product development at Taxware, suggests that we offer a session to explore the topic and reassemble the Council of Elders. We've gathered an impressive group:

Clockwise from far left: Diane Zajac-Woodie, Anand Bagmar (a principal consultant and quality analyst at ThoughtWorks), Adrian Howard, Woody Zuill, Markus Gärtner, Michael "Doc" Norton, Matt Barcomb, Steve Rogalsky, Matthew Heusser, Brian Bayer, Troy Magennis and Mark Ballstaedt discuss the "no estimates" software development concept at Agile2013.

Typical Software Estimation Little More Than Guesswork

CIO.com: If you're trapped in an elevator with an executive who asks what #NoEstimates means, what do you say?

Woody Zuill, the man behind the #NoEstimates hashtag: #NoEstimates is essentially a way to make decisions that don't use estimates.

Markus Gärtner, author of Acceptance Test Driven Development by Example and a speaker at the conference: Why would I do that?

Zuill: Why would you do estimates?

Diane Zajac-Woodie, business analyst with Erie Insurance: Every time I hear this conversation, I'm reminded of my personal life. I don't buy a product unless I know what the purchase will cost.

Zuill: That's my starting point for most people. It works well in that example, but we assume that works for software development. Why do we make that assumption? (By the way, I got my brakes fixed a few months ago: $300 was the estimate, $900 was the out-of-pocket bill.)

Zajac-Woodie: Nobody guarantees anything. It's an estimate, not a guess.

Zuill: Why do we do that in software development?

Barcomb: So we can execute to a schedule! (Laughs.)

Zuill: Why execute to a schedule?

Steve Rogalsky, who's speaking at Agile2013 about story mapping: Some people think, if you don't have a detailed plan, with estimates, then you can't prove that you're working hard. It's accountability. I'm not saying that it's a good form. It's just one argument I've heard.

Can Developers Convince Clients That Software Estimation Slows Them Down?

Zuill: I know we don't need to do estimates. I've been doing it for four-plus [years]. I'd like to talk to people who have also done no estimates.

Adrian Howard, a development generalist with deep UX and testing expertise: I measure the number of stories that finish in order to predict.

Barcomb: You're defining estimates as, "This piece of work that I am eyeballing should take so many hours." I think that's different than forecasting, which is looking at historical data - the number of stories we get done next will probably be similar to what we got done last month.

Zuill: I define an estimate as judging the amount of time something should take.

Howard: Let me ask a different question. What are people using to dissuade the client that estimates are getting in the way? So the client feels uncomfortable about the project and wants me to estimate. I know that will take extra work, which will make me later. How do we point out this will actually slow us down?

Adrian Howard (black pants) asks, "How do we convince the client to try a #NoEstimates approach?"

Brian Bayer, agile coach at Chemical Abstract Service ( CAS: I continually revise sizing as I go. I know what my cycle times are, so I can say, "The team spent three hours on this estimation exercise, which at our rate is so much of a story per iteration, which is so many points per year." Could you do something like this?

Howard: I don't think so. We haven't written it all down - and doing that will take longer than doing the tasks.

Barcomb: Part of [Zuill]'s premise is that estimates are used to make decisions. You want me to ... come up with a number. What are you going to do with that? Say [something]'s needed in a month, it takes a week to estimate but that estimate comes back as six weeks. What will you do with that information? If it won't move the date or make a difference, why do it?

Analysis: Who Says Agile Development Can't Be Faster?More: Bringing Common Sense to Agile Principles

Troy Magennis, president of Focused Objective and former vice president of Technology at Travelocity, lastminute.com and Sabre Holdings: That's the point, right? When we get asked to make an estimate, I often retort, "What would we have to do to change your mind?" I get hit with estimates when there isn't faith that there's a second release. It's when there's only one release that the customer wants to know exactly what he gets.

Gärtner: Marketing really doesn't need to create the advertisement for the new feature six months in advance. It can purchase the option for the advertising space and design the ad two or three weeks before go-live - by which time we'll know exactly what we'll build.

Modeling Value, Risk Helps Development Teams Eschew Estimates

Zuill: We're down in the details and need to be more high level. We need to talk about what people think they need to plan. We're not going to ... resolve these dysfunctions by figuring out how to give people numbers in a better way. What alternatives do we have to estimates?

Barcomb: To spend a moment on the point, if a client asks how we estimate and I lead with, "We don't," that won't go very well. So I defer that, focusing on modeling value and modeling risk. That allows us to move toward starting and stopping heuristics - when should we start a project and when should we stop.

Once you finish the exercise, you ask, "Which of these projects should we start?" They say, "This one, this one and this one." I say, "Great. We know what to start without doing estimates." There's no convincing, no argument.

How-to: 3 Ways to Be More Agile With Software Shipping Decisions

Zuill: That's great. I dive into this because people want to make decisions. Estimates are easy, and they make decisions easy. But does that really give us confidence that we have the right information?

Barcomb: How do others make decisions? Think about pharmaceutical companies that spend millions and billions of dollars on projects. They start them without knowing when, or if, the project will succeed. In fact, they know that only perhaps 1 percent of those projects will succeed.

Howard: If you offer to do one sprint at a time, and allow the client to fire you at the end of a sprint if he's unhappy &mdash even with working software delivered - that decreases the fear.

CIO.com: How many six-month projects could have been done in two or three months by building the most important 80 percent first? But because it was scheduled for six months and given to a "project team" to execute with a six-month schedule, it was destined to take at least six months. Guaranteed.

Zuill: That's what we do at my current company. We have too much work and not enough time. When we take on something new, we try to get them something to respond to in a day or two. We keep tweaking it until they get bored or have a new idea. That's different than building a "framework" and database design.

Case Study: Federal Agencies Embrace Collaborative Software Development

Deliver value quickly and stop worrying about what it's going to cost. I want something that will fund itself after the first week so that the savings you get are more than the cost to build the next increment. Every time you do one week of work for me, it saves 10 weeks of person-work for my team. So let's just do more of it.)

Michael "Doc" Norton, an engineering director at Groupon: In this case, we're creating things that add value, increase efficiency or increase revenue. If we can do it quickly, it funds the next piece. It's a different model than purchasing a product.

Barcomb: Estimates try to tackle a production or construction project - paying money for a "thing." We use words like that, but we're not building things. It's all design.

Zuill: By the time you can estimate well, because you've done it many times, you're doing construction work. You should abstract it, put it in a code library and work at a higher level of abstraction. This idea of when and how to stop doing the work - when we don't see additional value but see other, better opportunities to get more value - are models of thinking that mean we don't need to estimate.

Barcomb: Imagine if you could do things that fund themselves in a week.

Zuill: Many of our projects are like this. Forget the 80/20 rule. Let's just build the first 5 percent.

Eliminate Estimating Constraints, Give Clients Something Valuable

Bayer: Often you don't know what's valuable until you give the client something. I like this idea of very fast discovery.

Zuill: It doesn't matter how well I estimated the thing that nobody wants. Even with accurate estimates, if we get to the end and no one will buy it or use it, it has no value.

Barcomb: One very normal practice for next year's budget is to look at the project roadmap [and] come up with detailed estimates to roll up a budget request that gets shot down and normalized to what senior management thinks is a reasonable budget.

Rogalsky: That's right. It's waste.

Zuill: Let's get good at this work. Figure out the constraints that force us into estimates and figure out how to eliminate those constraints. We need to make good decisions, but can we prove that the estimates help us make good decisions? I don't think so.

Related: How to Advance Lean Software Development

One estimate I can make is how much it costs to keep a programming team working for a year ... As soon as we move past that, we get into trouble.

When we get our estimates right, we've proven that we've navigated to mediocrity. I've seen people estimate requirements, hit the deadline but do a terrible job. The requirements create churn that hurts the project.

Barcomb: Say you have three projects to pick among. Usually we'd estimate to find out what one to start. Another alternative is to start all three, figure out the one with the most value and build that.

Howard: That's better and faster than it would take to do full estimation of all three alternatives.

Mark Ballstaedt, director of IT at 1-800-CONTACTS: You've got me interested. I'd like to implement. Where do I start?

(Suggestions include forecasting, measuring the value as an investment, managing by adjusting scope - or just running full-out.)

Zuill, Barcomb and Rogalsky (simultaneously): Try them all!

Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.

Read more about agile in CIO's Agile Drilldown.