Feature Size: The Hidden Cause of Slow Delivery

Something I've become increasingly convinced of is that many missed commitments don't begin in delivery, but rather much earlier.
My best guess would be a roadmap meeting or a planning session. Often, it happens in the middle of a perfectly reasonable conversation while we are aiming to build something genuinely useful. What we may not notice is that the feature slowly grows until it becomes increasingly difficult to split.
And so, by the time the work reaches a delivery team, many of the conditions for the future delay have already been created.

The size paradox
When product managers shape ideas into product features they don’t always know what “too big” means for a delivery team. And besides, it is more useful to shape new features around our customers and the jobs they are trying to complete and not to worry about size at this point.
On the other hand, as we ask software teams to deliver these features we need to be mindful that in order to improve efficiency of the flow of work while also improving predictability, we need to split features into smaller chunks of work, so we get faster feedback, faster integration, and faster visibility of any problems. Coincidentally this also makes risk management effectively built into our process.
The joining up of these potentially conflicting needs is a critical part of being able to do the right work and get it done in the right way. Consider the following diagram.

To make it work, we need to correctly specify what represents a deliverable that stakeholders care about. Depending on what each meaningful deliverable is, from delivery team point of view, it could be represented by an entire feature or perhaps a package of work items (e.g. an Epic) or perhaps even a single work item. Any of these could represent a deliverable that someone needs. And once we have established our deliverables in the Product manager’s list or roadmap, that will enable us to use historical data to forecast based on the level we’re asked to.
This is an important policy for a team or department to establish. It helps us forecast with confidence that we know what our forecasts are for. It can guide us in figuring out how to report on our progress in a way that makes sense to both stakeholders and delivery teams. It decouples the flow of work of the delivery team from the concepts Product managers work with - e.g. features.
The need for smaller
I mentioned that delivery teams typically need smaller items for faster integration, shorter feedback, and risk mitigation. Smaller work items improve the flow and predictability of delivery teams. But smaller items are also useful at the higher levels.
It is the job of the product manager to ensure they find the right balance between value and size. It is everyone’s responsibility to monitor the size of deliverables, avoid inflating the scope and actively work towards shaping smaller deliverables.
Why do we care about smaller size of bigger packages of work? Because the principles of flow are exactly the same as they are for smaller granularity tasks one can find at the team level. In fact, when you work with multiple delivery teams it is even more crucial to have smaller items because team interactions and dependencies can cause further aging of larger items of work.
Ironically, item size at this level, which is typically given to product managers to manage can cause flow issues at the team level where the responsibility is expected to be with the deliver manager or the team. The only solution to this is to work in collaboration and actively monitor and correct size of work at all levels.


What’s so wrong with bigger features?
Many organisations have become comfortable with large features, epics and strategic initiatives as though size is simply an unavoidable characteristic of important work. In some cases there are even huge incentives to work on and complete bigger initiatives. This is a symptom of the “hero” narrative that we all get trained to admire by movies, media and story books alike.
But the story of the hero rarely happens in real life. And even when it does, the aftermath could end up costing more than any benefit realised by the unlikely success.
What's wrong with larger features is much the same as what's wrong with larger tasks. Longer feedback loops, increased risk, bigger dependency impact and more waste overall. There is of course more detail but you’d need to read my kanban series for more.
At the feature level the downsides are further amplified by multi team execution which adds up to even longer feedback loops, more risk, etc.
Larger features usually involve more people and so we need more conversations, identify more dependencies which results in more waiting and more decisions are needed. They take longer and so there are more opportunities for priorities to change and more chances for somebody to discover that another piece of work also needs to be included.
And so the feature doesn't just become larger but it also becomes more difficult to keep moving.
It's hardly surprising that these are often the features that begin to age.
Helping Product Managers See It Earlier
One of the reasons I wanted to write this article is make it clear that feature size is still largely within a product manager's control.
Before delivery starts, they simply can ask:
"Could we learn the same thing by delivering a smaller version first?"
and don’t take no for an answer.
Once delivery has started, monitor the tasks and look for opportunities to do less. With persistence and some coaching your team will appreciate the value and will start doing the same.
In the previous article, I argued that product managers need signals to help them know when to ask these questions. These signals are not a new invention. They are adapted from established kanban metrics. Feature size is another example for a useful signal.
A product manager shouldn't need to become an expert in forecasting or delivery planning to recognise that a feature looks unusually large. If previous features have followed a fairly consistent pattern, then work that sits well outside that pattern deserves a second look before anyone commits to delivering it.
A good product tool should be able to provide such signals automatically. Without asking anyone to calculate story points or interpret complicated charts.
Sometimes that's all we need to start asking better questions.
Looking Ahead
Product managers can influence many of the things that make delivery predictable, both before and after delivery starts. But there are more questions to consider.
For instance if features are sensibly sized and the amount of work in progress is under control, why do some teams still deliver more predictably than others?
The answer has less to do with individual capability than with the stability of the system teams are working within.
More on that in the next article.