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

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.