Thanks to my first post, i had the chance to have very interesting chat with some cowokers.

One of the main concern was the mandatory apsect of the estimates in specific situations, mostly in order to arbitrate between two projects.

First of all, let me clarify my thoughts about estimates. In order to provide reliable estimate, the following criteria have to be gathered :

• Team should know itself perfectly, knowing precisely what are the strenghts and weakness of each member.
• Team’s codebase should be either blank or without defects
• product should entierely identified and specified, and the Product Owner, as the domain experts, 100% sure of what the final product should be.

I’ll post more on this later, but in my opinion, thoses conditions are at best anti-agile and at worst impossible to get.

Considering this fact, it becomes obvious that in our everyday work, no estimates could be actually accurate. Even if we know our codebase, we are never sure our assumptions are correct. Maybe we’ll have to completely refactor a code area that did not get the initial crafting it deserved?

This lack of precision make estimates a decision making tool of low reliability. Unluckily, estimates are often considered as a sufficient communication tool and justify that product stakholders do not need to work in the same room.
I’d rather like integrated teams, where domain experts, devs, product owners, QAs and Ops are working together, in the same physical place, that facilitate a very short feedback loop, and enable a truly collaborative build of the product. This kind of team often manages to identify then plan achievable user-stories in a sprint, based on business needs. This team’s velocity is now more than a managerial data, but also a value-oriented business data : the number of user-stories going to prod per sprint.

This metric is useful, because it gives more visibility on what a team can achieve in a near future, in a way that is way more reliable and tangible than the traditionnal mand-day estimates.

Another dangerous effect of estimates comes from a psychological aspect : We, developers, are often afraid of failure. When a given task oversteps its original estimates, we feel like we are experiencing a failure. So the estimates tend to become commitment, at the really moment we communicate on it.
When we tell to the team, or managers, that a given task is achievable in one day, we implicitely commit ourselves to perform this task in one day. And two results are possible :

• the estimate was too optimistic : in order to finish in time, we’ll naturally tend to lower the qualtity of our code
• the estimate was too pessimistic : we tend to lose focus, and the productivity of the team can be lowered, in a totally unoticeable way.

But we, developers, feel way less guilty in the second case. So what? Naturally, we tend to add a security range when we give our estimates in order to avoid the first case. And this harness is added in percentage. A common practice is to add 30% to the original estimate. Yes, we literally add an “I don’t truly know my system as well as i want” time to an unreliable estimate, just to not being late on our delivery, to make our managers happy!

That’s why, in my opinion, estimates should not be used as a decision aid tool.