InfoQ had a round-up of ideas about “How Long Would it Take to Build the Product?”. It was funny (ha-ha funny) to read some of the responses. One person suggested that upfront estimations end up in a fixed scope, which is anti-agile. If I was new to agile, I would read it this way: if you’re REALLY agile, estimations are not for you.

Well, that’s a great way to set up expectations for the new agilist. If you want to pick up the pieces later, that is.

It seems that developers don’t really need estimations. They can work without any planning or time limit (not effectively or efficiently, but they can). True time lords.

But estimations are a tool for the project sponsors. The ones who pay for the project. They want to know when they’ll have something to show for their investment.

If there’s no agile experience in the organization, when the sponsors ask:“when will it be read?y”, they know that they’ll get a date, to which they’ll need to add 6 months, and that at the end they’ll need more testers. It’s painful, but they learned from history, and this gives our poor sponsors some kind of predictability in their life.

If there are already agile projects in the organizations, the sponsors already know that it’s not about fixed scope and date. They’ll get what they can by that date. Sure, they’ll always want more, but they learned to live like that. That’s another way to have predictability in their uncertain life.

But if the organization is in transition to agile, the sponsors are very touchy about these things. They are looking for some predictability, and the last thing they want to hear is: We’re agile now, we don’t give estimates.

Wrong answer.

Forget about pure agile, and give your sponsor confidence this new way of developing software can actually work. That his trusted developers are not some inmates taking over the asylum.

Estimations are a way to introduce predictability and trust to all the project stakeholders. It allows the organization to plan ahead, know when the team needs more people, or to transfer people to other teams, to raise money or just put a date on the calendar when the marketing team can start promoting the new product. It’s not much, but way better than the black hole of uncertainty.

Remember: Agile is about collaboration. And not jut with the customer, also with your boss.