Here’s an anecdote for you: Imagine a dev team that performs task estimates expressed in “story points”, Agile style, and encounters a large estimate. Large, in this team, means “13 or more.”

Then in one of these sessions, a specific task initially received an estimation of 13 story points. This marks the team’s threshold for considering the division of tasks into more manageable pieces by convention.

After performing the division, the first segment of this task was then estimated to be worth 8 story points. This led to a deliberation on the value of the remaining portion.

Is it 5? (13 minus 8)

When splitting large tasks–those that are estimated to be worth a high number of “story points”–it’s an opportunity to abandon the initial estimate and start fresh for a more accurate outcome.

This approach is crucial, particularly for complex tasks with inherent unknowns. They should not be treated as simplistically as slicing a cake, because that doesn’t do the creative process of our work justice.

That’s why, contrary to a straightforward subtraction, the remaining task should not simply be labeled being worth 5 story points (13 minus 8).
I want to argue for the principle that splitting tasks is more than a numerical exercise; it serves as a safeguard against inaccurate large-scale estimates.

1. Splitting a task fundamentally changes our understanding of what needs to be accomplished. There’s a difference between thinking about the forest (and its macro scale phenomena) and about individual trees (and their individual properties). Reducing the scope or resolution of a problem helps in pinpointing specifics that a broader perspective might miss.

2. Daniel Kahneman popularized this notion that “what you see is all there is”, which means our evaluations are influenced by our current focus. When examining a task as a whole, we might activate different ideas than when breaking it down. To properly combat the potential overconfidence in our initial estimates, breaking down a task that is identified as “too large to work on” needs to go hand in hand with discounting the original estimate. Acknowledge that it’s likely that it was not just large, but probably also inaccurate.

3. On the flip side, reducing task size can significantly enhance problem detection. The decision to split a task becomes an act of breaking the “known knowns” into smaller, more understandable pieces. This not only helps in managing the work better but also in identifying any previously untackled unknowns. For instance, issues specific to certain aspects of implementation, like SQL injections in the context of database interactions, might only become apparent when tasks are dissected into finer details. Changing the granularity facilitates a more thorough examination, making it easier to identify and address potential problems early in the development process. Again, “what you see is all there is”, but as a human, you can’t see a thousand things at full resolution, so changing what you look at changes what you can think of.

4. Viewing estimation as a simple mathematical equation like slicing a cake fails to account for the inherent uncertainties of creative and complex tasks. Writing two essays of approximately half the size of a large one doesn’t necessarily divide the effort. The creative process is non-linear, and smaller tasks might require more time due to the need for cohesion and clarity in all of them.

5. Related, there’s probably some very practical and technical overhead. On the technical side, in programming, splitting one function into two to reduce its size increases the required lines of code by the overhead of declaring a new function and calling it. On a less obvious, creative side, the task of splitting a function is also about understanding that dividing work introduces new problems and changes how the existing code will be reas. Then there’s overhead such as designing proper interfaces and refactoring code, or writing documentation and adding tests for new API.

A reevaluation of the smaller tasks acknowledges our shortcomings in estimation, especially as the scale of the task increases. The team’s original rule of thumb to not continue with tasks worth 13 story points or more is an attempt to acknowledge exactly this. The problem is not that the number is high (e.g. too large to be entered into a form field), but that high numbers indicate that the represented task could hide many traps.

Therefore, when considering the second portion of the initially large task, automatically assigning it 5 story points misses the point of splitting a large task in the first place. Instead, each segment of the original task deserves a new evaluation (ideally, free from the bias of the original).

To split a large task into smaller ones should uncover parts of our incomplete understanding of the original one. Otherwise, the process of splitting becomes mere ceremony, and performed in a team meeting wastes collective time more than it helps understanding. It’s still maybe not at all pointless – after all, you end up with smaller tasks that you can focus on –, but it’s more of a formality, more ritual than understanding.