As in just go read the f’in book. ;)

Steve McConnell is like Jesus, and I would definitely run out and buy the bibles Code Complete and Software Estimation, Demystifying the Black Art

There are many many instances where estimates SHOULD be taken as commitments. It connects the person making the estimation with accountability which reinforces the whole refinement process each of us go through as we develop. Incorrect estimations with absolutely no consequence certainly doesn’t bode for a higher degree of accuracy over time. Is Bob going to give better estimations cause he’s a good guy? Hell no..he’s giving better estimations because if it doesn’t they’re gonna boot his @$$.

The great Steve McConnell once said, “estimations should be good enough to be within 25% correctness, 75% of the time”.

Don’t assume I am removing all accountability for false or wild guesstimates, but I am suggesting that holding people to estimates as measurable actions and timelines is a mistake.

After all, would you want to be held responsible on timelines that where only accurate within 25% 75% of the time? Do not take estimates as commitments is the moral here, not remove all instances of accountability.

#1 CoWorker Accountability
The unit of 1 week in the Scrum process is advantageous as this is something with a reasonable amount of granularity.”Accountable Commitments” can also mean under the context of being held accountable and making commitments to *each other* and not necessarily to upper management. I wholeheartedly agree that a Scrum Dev Process benefits greatly from co-worker to co-worker commitment. That underlying promise to do our individual best to get X unit of work done this week. This is a much more personal level of social connection within the workplace and accountability from the fact that not accomplishing your goal simply means you let the group down and didn’t do your part. Again this wasn’t meant to imply accountability to steak holders necessarily.

#2 Stakeholder Accountability
“Nobody should ever be held accountable for estimations” -uhm what? That’s a huge load of crap. Who in the world would want to work with someone that said “Hey this project will take 1 week…buuuut don’t hold me accountable for it”. Of course estimations change through time and are very organic in nature as the boundaries of the project and requirements change through the dev process. But to blatantly say nobody should be held accountable is a huge load of crap. I’m calling BS here, you totally just dropped that to get some flame action!

Winston Churchill once said “Plans are worthless, planning is priceless.”

Estimations are part of planning, so to that point I agree they are a necessary evil. It is when that planning to took literally into inflexible expectations and plans that they doomed for failure.

I hope your key word there is SHOULD. The unfortunate reality is that in real life we ALL are held accountable to our estimates every day – all the way from “What time will you be home, honey?”, or “how long will it take you to clean the garage?”, to “how long will that meeting last?”

Projects need planning. Remember the old adage – “Failing to Plan is the same as Planning to Fail”. How can we adequately plan without estimating the amount of work that it takes to do something? Those signing the paychecks need to have these estimates so they can plan their business, budgets, and other initiatives. Therefore, estimating is something that MUST be done, and because of the importance of the outcomes – should be as accurate as possible.

Most of all – our estimates set expectations. The biggest cause of failure is the unmet expectation. During estimation, caveats must be set, assumptions documented, and customers and users of those estimation need to be painfully made aware that “things” happen during the development process. Hence, the need to be assertive about setting expectations, communication, and adjusting of scope when necessary.

Bottom line – we are all held accountable to our estimates, but by communicating and setting the expectations correctly we can help the planning process continue smoothly.

breaking your work to smaller tasks and considering unknowns makes an estimate close to what a task will take to complete.