The biggest problem I have with splitting tasks is reluctance to do duplicate or unnecessary work. Breaking down tasks into smaller tasks means you must do duplicate work. The trick is to minimize it.
If you try to make no unnecessary work, you'll end up having to do everything at once.
Example: you want to refactor a program with two modules A and B where B depends on A. The least wasteful way of doing it is to refactor both modules together. But it's also the riskiest and hardest to estimate.
The broken down way is to refactor A and adapt B so that it works with the refactored A. After that you would refactor A, which would then risk making the adaptation effort very short lived.
If you want to do zero throwaway effort, you often can't break down the task. I have 20 years of experience and I still often find myself reluctant to do throwaway/temporary job in order to divide work. Instead I find myself doing multi-week efforts with zero yaks left unshaved.
If you try to make no unnecessary work, you'll end up having to do everything at once.
Example: you want to refactor a program with two modules A and B where B depends on A. The least wasteful way of doing it is to refactor both modules together. But it's also the riskiest and hardest to estimate.
The broken down way is to refactor A and adapt B so that it works with the refactored A. After that you would refactor A, which would then risk making the adaptation effort very short lived.
If you want to do zero throwaway effort, you often can't break down the task. I have 20 years of experience and I still often find myself reluctant to do throwaway/temporary job in order to divide work. Instead I find myself doing multi-week efforts with zero yaks left unshaved.