D Is for Decomposition: Breaking Work into Subtasks

Task decomposition is probably the most underrated skill of a developer, and not much time is devoted to its development.

Most likely, there will be a series of notes about task decomposition, but today I would like to draw your attention to such an important part of decomposition - this is how the task is decomposed.

When decomposing a task, there are a number of questions you can ask yourself to help you understand exactly what the task will be easy to work with (for you or a colleague):

1. Do I understand what they want from me? (most important question)
2. Do I understand what a task looks like in ready (DOD) status?
3. Can I describe all the steps that need to be taken to complete the task? For example, can I make a list of subtasks and will it be complete?
4. Do I have all the prerequisites to start working on the task, and are there any dependencies or known blockers?

If you cannot answer unequivocally "yes" to all of these questions, then this means that the problem is not sufficiently decomposed, and you need to continue the process of detailing it until you receive an affirmative answer to each of the questions.

The clearer the task, the faster you will complete it, and the faster the business will receive value. Therefore, you can often ask these questions to the customer himself.

True, sometimes it happens that it is impossible to decompose the task further or add some context to the task due to uncertain factors. For example, when you create a bugfix task.

There shouldn't be a bug - that's the whole task, but what steps need to be taken is still unclear. You can also work with this and I will talk about it in the following notes.