←back to thread

Always Multiply Your Estimates by π (2013)

(web.archive.org)
268 points behnamoh | 1 comments | 27 Sep 21 04:48 UTC | HN request time: 0.297s | source
Show context
entrep ◴[27 Sep 21 06:58 UTC] No.28667859[source]▶
Is this doable?

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
replies(4): >>28667980 #>>28667993 #>>28668420 #>>28668669 #
1. throwawaylinux ◴[27 Sep 21 09:19 UTC] No.28668669[source]▶
I also don't know why this is getting downvotes or accusations of micro managing.

Maybe it is that you said break it down as much as possible rather than as much as necessary.

I hate administrative busy work and micromanagement, but planning is essential for almost any large project, and planning means breaking things down into smaller steps. Estimates are data that drives all planning, so if your estimates are really that far wrong you have to take steps to manage that issue, not just multiply by 3 and call that your estimate.

Breaking down tasks further absolutely can help estimates (within reason) and it can help identify other tasks or dependencies etc.

Sometimes a task is just really difficult to give an estimate for no matter how much it is broken down. Sometimes you don't even know how to break it down or what exactly the steps along the way would be, you may never have done something similar before, you may be relying on development of novel techniques.

Still, in those cases you still don't just multiply by 3 and call that your estimate. You have to call out that as a major risk in your plans, and the project may have to be changed accordingly. For example it might be decided that in fact the company won't start making commitments or wider plans on the success of this project, but rather run a prototype project instead.