Accurate Estimates - the ultimate oxymoron?

> simply using the velocity as a measure

Though I've note yet read the blog entry, still I'll venture this:

I teach teams to estimate and track how they deliver against that estimate (using StoryPoints or IdealHours and a Sprint burndown), precisely because that's how we learn (over time) our real velocity.

It's true that mature teams sometimes stop estimating and use only velocity to plan. The first time they do this, they are using "yesterday's weather", a familiar Agile pattern. The second time they do it, they are using "last week's weather", and the next time "last month's weather". This analogy suggests that eventually they could find themselves using "Christmas's weather" in July :-)

But I'll take the time to read the entry when I get home, too :-) I'm at RoCoCoCamp in Montreal and having a blast!

I dont buy the argument:
"it wouldn’t change the amount of time they’d have taken. And we’d be short about 5 to 10 percent of the time to actually build the software. Oh boy, we sure made a good decision of not going even slower!"

Not doing estimates is like fombeling around in the dark.

I wouldn't agree - I think we have to really look at the value a process delivers that is (almost) always flawed (see Google's take on performance appraisals). By flawed I mean usually fails/results in conflict of some kind.

As mentioned in the above comment, there is much more value in "Yesterday's weather" and gut feel than there is punting on exactly how many days it will take to complete a task.

Here are a couple of reasons why estimation is still time well spent.

1. An overall estimate is usually needed to actually start a project within a business. It's certainly needed for contracting situations, which is where I come from.

2. Estimating stories/features is a good way for a team to work through the stories and get to know them.

3. Estimation at the story or feature level is also necessary to allow the customer to prioritize, which is a critical component of an agile process.

4. I've seen a lot of teams respond well to a reasonable target, especially one they've set themselves. Setting those cycle targets and hitting them builds confidence all around.

Once you've done these things, the overall estimate to complete a given scope just falls right out, with no extra work. Estimating at the story level is something you need to do anyway.

I have always considered project estimation discussion a chicken and egg problem. As people have already mentioned, most of the time the business will not start without estimates. But estimates upfront are most of the time guesstimates, cause you will not know exactly without building it. These initial estimates are usually based on experience (and at best on prototyping), but most of the time you are not asked to rebuild the system X, so that your experience will serve you well 100%. And a prototype is still a prototype. What is more important in my opinion is the re-adjustment process, the weekly/iteration based re-adjustment. Unfortunately, not everybody likes this part and will almost always mention your initial estimates as the "promises" you made.

./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder

Until we estimate at the story level, we don't have any idea whether a feature is this big ### or this big ################# because of the assumptions unrevealed at that point. As long as this uncertainty is made very clear, up front estimates can serve some general purpose. For a brief moment :-) until things change, lol.
deb

I've often wondered why we, as a profession, struggle so much with this. When I call a plumber or take my car to a mechanic, they're not always sure of what they'll find but I'd be crazy to just let them start work with a "when it's done, it's done".

In fact, mechanics are pretty agile. They're give an estimate and, if they find that the work is going to exceed that initial estimate, they'll call me and get a thumbs up on the new work.

It's not that estimating is bad, it's our industry's expectation that an estimate is a commitment, not an estimate.

I also agree with Deb. If you don't estimate up front, how exactly are you computing your velocity? Estimating in story points is still estimating.

The difference between a programmer and an auto mechanic is, like you said, when the mechanic finds that it's going to exceed the estimate he is allowed to give a new estimate. Programmers, more often than not, are held to the original estimate no matter how big the project grows. For some reason people have the mindset that since we're not creating solid objects we should be able to manipulate applications with little or not added time.