How to Move Beyond Project Estimates and Provide Better Value
If software development teams can take the time they spend estimating how long a project will take and start to execute that project instead, they can go that much faster. But what does a world without estimates look like -- and what might it mean for the business?
Mon, September 09, 2013
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:
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.