Always Multiply Your Estimates by π (2013)

A better approach would be to break it down as much as possible. This has the following benefits:

  * You will identify tasks you haven't though of

  * You will get a better picture of the total effort needed

  * It will be easier to provide grounds for your estimates to stakeholders

  * Developers will see progress as tasks get closed

  * Commits can be traced to specific tasks

  * Better estimates for remaining work during sprint/iteration/what-ever-you-call-it

Eisenhower's quote "Plans are useless, planning is essential" matters here. Having clear checklist of things to do before release (same as a surgeon or pilot) is absolutely useful in realising just how much f######g work is ahead of you.

This helps the team slow down and be less optimistic (the developers natural state).

Yes I agree with below comments that the code is the source of truth (and you need to find ways to sync from the code to other management systems (like tickets). The worse this sync is the less software orientated a company is.

But being able to link your commits to some "ID number" is totally helpful in this regard. No matter what we need to co-ordinate with others in the org, and that co-ordination had better be automated 95% of the time or we are in a world of meetings.

But yes, the essence of the article is "you can never predict the unknown, so multiply by X as a buffer". [#]

The distinction between the article and the commenter is the article hopes to compensate for "unknown future events" and the commenter believes he can reduce his own amount of accidental estimation mistakes. Both can co-exist.

It is reasonable to take into account all our own mental failures when making estimates (and the commentators checklist style can help improve that) - but you cannot take into account the inherent problems (hence using pi).

I would even go so far as to say if you just do quick estimates, multiply by 9, if you take care in your estimates, you can just multiply by 3.

[#] The organisational problem with this is it is fine for the estimators to multiply up, by the more humans in the reporting chain, the more they add buffers (every project manager knows to multiply estimates by 3) so very soon buffers get wildly out of hand. Having things like JIRA where the estimators directly report their estiamtes (and senior mgmt gets the sum) has drastically changed the reliability of through organisational reporting and is leading to the death of project management as a profession.