Work Item right sizing: The delivery leader’s guide to dealing with oversized work

As humans we often fail to be rational but excel at “rationalising". Our brains prioritise metabolic efficiency and social survival over objective truth. To conserve energy, the brain uses confirmation bias to filter new data through existing neural frameworks rather than performing the more "expensive" work of updating these neural pathways.

When we encounter contradicting facts, that triggers cognitive dissonance, literally activating the brain’s pain centres and so prompting us to instinctively twist logic to relieve the discomfort. And because our beliefs are often tied to our identity and our "tribe" the amygdala treats a challenge to our worldview as a physical threat, casting our intellect in the role of a guard tasked with protecting our ego rather than a scientist seeking facts.

With this in mind it’s easy to see why adopting new practices is hard.
Consider a typical reaction when a feature delivery goes wrong:

“It turned out to be bigger than we thought.”

Then rationalising takes over “it was just too complicated”, “we couldn’t have possibly known beforehand”, “some work is just emergent” etc.

If you’ve followed these blog series from the start, you may sense where this is going.

Oversized work is rarely a failure of team practice. It is almost always a system and leadership failure that shows up late, expensively, and repeatedly.


Big work is the number one enemy of flow


From the perspective of flow efficiency, having large work items is the worst thing.

Here are some of the reasons. Large items:

•     age for a long time before delivering value
•     hide multiple risks inside a single commitment
•     delay customer feedback
•     impact cycle time distributions
•     make forecasting less reliable
•     amplify the impact of blockers

The importance of this is usually lost in most organisations. Rationalisation kicks in “We just have to do it!”, “We are running out of time in the market!”, etc. So organisations keep pushing big chunks of work into delivery systems and then fire people for not working hard enough.

Batch size is one of the most powerful levers in flow management. Small batches lead to better predictability, large batches… you get it.


How does it always end up with blaming the team?

Modern teams are used to conducting retrospectives and lessons learned sessions. Conscious engineers will always look for ways to improve. This leads to teams accepting that they can do better. But it doesn’t mean the problem or the blame always sits with the team.

This is convenient and often exploited by other parties. In many organisations, the ways of working and the culture have shaped people’s behaviour so that they avoid being blamed at any cost and so people will do a lot to avoid being in the mix of who’s to blame.


There is a better question to ask:

Who decided this was acceptable to start as a single item in the first place?

But this is often an inconvenient question. Teams don’t usually choose to work on oversized items. Those come from roadmaps, or because of specific funding or from dependent initiatives or from commitments made before delivery was consulted.

Blaming teams for size after the fact is easy but preventing oversized work requires earlier leadership decisions. That’s hard and rarely seen.


Work item size is truly measured by age and not estimation


One of the most useful things about Work Item Age is that it exposes oversized work in real time.


If an item is ageing well beyond the bulk of your historical cycle time, one of two things is true:
    1.    The system is blocked, or
    2.    The item is too big
Or often both.

When a large piece of work starts to drag, the most common reaction you’d come across is:

“We’ve made so much progress, we might as well finish it.”

Somewhat counter intuitively, this is sunk cost thinking, and it’s very expensive.

Large items are often not one thing. They are multiple valuable pieces bundled together.
If we treating them as one we will see

•     longer delays before any value is realised
•     higher risk of total failure
•     fewer opportunities to learn and adjust

Often people oppose breaking up work after it has started. From flow perspective this is not a problem and not a failure. In fact, it is often the most responsible thing you can do.

Looking to protect flow? Try work item breakdown


The sentiment you typically get in organisations is that breakdown of work is not worth the effort. However this is a reframing that is well worth going for.

Some people seem to see the breaking down of work items as just a planning or refinement hygiene exercise. But what it actually does is much more important and that makes it a flow protection mechanism.

Breaking work down is very useful because it simultaneously reduces work item aging and the risk associated with work. It helps reduce forecast variance therefore making your forecasts more stable and it has a significant impact on dependency reduction which is often the main reason for delays.

And one more thing that is often overlooked. Breaking down work creates smaller work items, and that in turn creates more frequent opportunities to stop doing the wrong thing.

Why work breakdown must be enabled (even if it seems trivial at first)


It is not uncommon for teams to be aware that work is too big. And to clarify, this usually is not a team level work item that is too big. That can be an issue for flow too , but the problem is typically one level above at the feature/portfolio stage.

Teams often lack is permission to split at that level. (And they need to have it)

Why? Because breaking work down at that level requires one or more of:

• renegotiating scope with stakeholders
• changing commitments already communicated
• challenging pretty roadmap
• delivering partial value instead of “the full thing”

Breaking down work at this level requires leadership to make that option available.

If leaders punish scope change but demand predictability, teams have no other option but to keep pushing the big item forward and hope.

But you do know that hope is not a strategy, right?

If you are bought into the benefits of work breakdown then consider acting before work starts.

This is where pull-based systems and breakdown support intersect.

Some questions you can ask to help you break down at the feature level before works starts

• “What is the smallest valuable thing we could deliver?”
• “What happens if we delay the rest?”
• “Which part carries the most risk?”
• “What would give us feedback sooner?”

To ask this questions, teams need to be able to challenge roadmaps, amend commitments and re-negotiate. These are not technical questions and they can only happen with leadership support.



Why is work often too big?


You can do you own root cause analysis and sure your context can be somewhat different. But there are some common themes like

1. funding models reward big batches
2. governance structures prefer projects over outcomes
3. planning cycles that seek long term commitment
4. fear of incremental delivery
5. lack of trust in teams and customers

Breaking work down exposes these tensions. That’s why it’s resisted.

But avoiding the tension doesn’t remove the cost, it just delays it and often multiplies it.

If your team thinks that everything Is “Too Big to Split”, then perhaps your thinking is too narrow.

Have you heard of “This can’t be broken down.”? While this is common, it’s rarely true.


You can dig deeper and uncover the actual reason, e.g.
“We’ve defined value too narrowly”
or “We’re optimising for internal milestones”
or “We’re afraid to release partial outcomes”
or “We don’t want to renegotiate expectations”


From a flow perspective, value can often be delivered in thinner slices than organisations are comfortable admitting.
Work item breakdown is about learning faster
The real pay off of breaking work down is the good old fast feedback loop.

When your work item are smaller then you validate assumptions sooner and reduce the cost of being wrong. Also risks become obvious earlier and you have time to change course.

In uncertain environments, learning speed matters more than delivery speed. Do you think your environment is certain? Perhaps think again!

A simple rule you can apply: If an item is ageing past where most work finishes, ask:


“What would it look like to split this right now?”

If you never ask, big work items will keep sabotaging your system.


One final thought

Some work really needs to be large. That’s fine.
But it should be rare and explicit and acknowledged as risky

If you always have big work items, you are not managing flow, you are just gambling with it.


In the final post of the series, we’ll look at Pull Signals, and how letting the system tell you when to start work is the final step in moving from activity management to true flow-based leadership.

​Links to all articles in the series here