There’s a piece of advice that has become so standard in software development and knowledge work that questioning it feels almost reckless: break your work into small, manageable tasks. Smaller stories. Shorter sprints. Atomic commits. The logic is sound on its face. Big tasks are hard to estimate, easy to block on, and satisfying to avoid. Small tasks are tractable, movable, and completable. So you split everything.
And then the project takes longer than it would have if you’d just done the thing.
This isn’t an argument against decomposition. It’s an argument for understanding what decomposition costs, because that cost is real and frequently ignored.
The Hidden Overhead of Every Split
Every time you divide a unit of work, you create coordination surface area that didn’t exist before. Two tasks that were once one thing now need sequencing, handoffs, status tracking, and someone to notice when the first is done so the second can begin. In software terms, this is analogous to what happens when you decompose a monolithic function into microservices: the logic gets cleaner, but you’ve introduced network calls, failure modes, and latency that simply weren’t possible before. The complexity doesn’t disappear, it shifts.
In project management, this overhead shows up as what researchers sometimes call “transaction costs” of work management. Each ticket needs to be written, refined, estimated, assigned, updated, reviewed, and closed. In a well-oiled team with a backlog grooming rhythm, that process might take fifteen minutes per task. Now imagine a feature that one developer could have built in three focused days gets split into fourteen tickets because the team wants granular visibility. That’s potentially three and a half hours of overhead for a task that took twenty-four hours of actual work. And that’s before accounting for context switching, dependency queuing, or the meeting to discuss why ticket 9 is blocked on ticket 7.
Dependencies Are Where Decomposed Work Goes to Wait
The deeper problem is dependencies. When a large task lives entirely in one person’s head or one pull request, it has no external dependencies on its own progress. When you split it into ten tasks, you’ve introduced up to ten potential blocking points.
This is especially painful when the splits are too fine-grained relative to team size. A team of three developers working a sprint with thirty tickets is not going to move faster than that same team working fifteen thoughtfully-sized tickets. They’re going to spend more time in ticket state management than in the work itself. Jira (or Linear, or whatever you’re using) starts to feel like the job rather than the record of the job.
There’s also a subtler dependency problem: discovered dependencies. When you break work down in a planning session before the work has started, you’re decomposing based on what you know. But some tasks only reveal their true shape once you’re inside them. Overly granular decomposition can actually make this worse, because it commits you to an execution sequence before you understand the problem. The developer halfway through ticket 4 realizes that tickets 6 and 7 are based on an assumption that ticket 4 just invalidated. Now you have a coordination problem that requires re-planning, not just re-doing.
The Feel-Good Trap of Velocity Theater
There’s a psychological dimension here worth examining honestly. Small tasks feel good to close. Closing things releases dopamine. A board full of moving tickets gives the impression of a team in flow. This creates an incentive, usually unintentional, to decompose work in ways that maximize completable units rather than delivered value.
This is your productivity system optimized for feeling busy at the team level. The metrics look healthy. Velocity numbers are up. The burndown chart trends correctly. And the feature that was supposed to ship in Q2 is still two weeks from done in Q3 because the decomposition strategy optimized for the appearance of movement rather than the actual movement.
Some teams notice this and respond by making tasks even smaller so they can close even more of them. This is exactly the wrong instinct.
When Decomposition Actually Helps
None of this means you should work in massive, ill-defined chunks. Decomposition earns its cost in specific situations.
Parallel work is the clearest case. If a task can be genuinely split along lines where two people can work simultaneously with minimal coordination, the split is worth it. The overhead is justified by the parallelism. A backend developer building an API and a frontend developer building the interface that will consume it is a good split. Both can move forward with a shared contract (the API spec), and the total elapsed time compresses even if total work hours stays similar.
Decomposition also pays off when tasks have meaningfully different risk profiles. Separating the risky, exploratory part of work from the mechanical, buildable part makes sense because they deserve different treatment. The risky part benefits from being a small spike or prototype; the mechanical part benefits from being a well-specified ticket.
And decomposition helps when handoffs are real, not just organizational theater. If a designer genuinely needs to complete work before an engineer can start, that’s a real dependency that benefits from being named and tracked.
The test isn’t “can this be split?” Almost anything can be split. The test is “does splitting this reduce total elapsed time or just redistribute the work into more visible pieces?”
The Right Grain Size Is Contextual, Not Universal
The advice to “make tasks small” is too context-free to be useful as a principle. The right size for a task is the size at which it can be owned by one person, completed without external blocking, and reviewed without a meeting to explain what was even attempted. For some work, that’s a few hours. For other work, that’s several days.
Teams that perform well over time tend to develop a feel for this calibration. They’ve felt the drag of over-decomposed sprints and the opacity of under-decomposed ones. They split along real seams in the work rather than splitting to hit a story point ceiling.
If your project is running late despite a full, healthy-looking backlog, the problem might not be execution speed. It might be that you’ve divided the work into so many pieces that the coordination of those pieces has become the project.
