Always Multiply Your Estimates by π (2013)

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

Let me guess, you work as a low-level manager?

What you are suggesting is basically micromanagement-by-scrum.

* Identification of tasks you didn't think of is a fallacy in software engineering. There are very few actual tasks when it comes to writing the software. Yes, sometimes you can break a change. For instance across components or features, but most often that has already been done when a developer gets a task. Most of the additional tasks you can come up with are either trivial, come after the end of development (e.g., deployment), or are completely arbitrary and not self-contained (write this class or that function). Very seldom a software development task can be broken down into several roughly equally complex subtasks.

* It follows that you don't improve your estimate by writing down all these side tasks in your task tracker. You increase the busywork and friction and become less agile. These subtasks tend to become stale quite quickly when requirements change.

* Your stakeholders don't understand anything about aoftware development. Unless your task is trivial to begin with, there is little ground in any estimate.

* Developers either see progress through code reviews, technical discussions, or the source code itself. No need to maintain a list of tasks in some tracker for them.

* Commits should be self-contained and have a meaningful message anyways. It should be trivial to trace them to the main task.

* Your estimates won't improve at all if you break down your task arbitrarily.

If you create subtasks like "write the tests" it might help a junior to structure their work approach, but in a professional environment it is pointless. Worse, if time is at the essence, some product owner might ask you to deploy "just an MVP" before that subtask is done, postponing it forever.

The only reason to break down a task is when there's a time-like dependency in the process. E.g., I can do X after Y gets deployed. Or I need to remove Z once Q is done. Mostly, tasks like Y or Q will involve operational aspects (data migration, experiments) so the subtask will have a different owner or at least a different context.

> A better approach would be to break it down as much as possible.

Better still is to do that, and then multiply the end result by π.

(as explained in the article, it's mostly to compensate for scope creep, and that isn't in your list of benefits)

Developer (and team lead)

Surprised by the downvotes. I'm just sharing what I've learned the hard way over the last 6 years.

We can easily tell that the sprints where we managed to break something down further, has been better estimated and more productive.

Call it micromanagement if you'd like. What is working for one team might not work for another.

I am going to jump in an defend this. Mostly.

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.

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.

Most programming can be made modular in a way that many, even all some times, functional requirements can be made distinctly areas of the codebase. It makes sense to break them down to singular subtasks for making various requirements explicit. Add general things such as documentation, deployment etc, and you're able to provide far better estimates.

Through retrospectives teams slowly but surely create a checklist of things to consider when estimating and my experience is that teams get better and better at anticipating the scope of a task and estimating it.

I've had that experience too, but it's become increasingly clear to me over time that the causation flows the other direction. The sprints that feel more productive are the ones that happened to have a lot of break-down-able tasks; the sprints that feel less productive are the ones where you have an important but hard problem with no clear solutions or break points. That all works out fine for teams that have to do a lot of greenfield development, sure, but does it reflect anything other than simple ease of planning?

> The sprints that feel more productive are the ones that happened to have a lot of break-down-able tasks

That’s a great point which I will take with me. Might be somewhat biased since we only done greenfield.