How to Split Work and get Incremental Value


The importance of work breakdown

Any significant complex effort is split up into smaller pieces and that’s how it gets implemented. And maybe it’s the next release of your product or just a large solution capability that you are building. In either case, it matters a lot how exactly is that work being split. Many initiatives fail simply because of ineffective breakdown of work. 

So, the big question is: How do we break down larger effort into smaller pieces in a way that supports great results?

To answer this question, we have to take a deeper dive. 

A common mistake

Here’s a common scenario that leads to poor outcomes. Imagine we have a large work item, a new big feature, that we would like to implement in our product. And what happens is that the feature is split into smaller chunks, as follows: here’s the UI work, the business logic, the connectivity module, and the database. Different people or maybe even different teams start working on their respective chunks. But the problem is that neither chunk represents actual customer or business value. There is no point in UI without Database, nor in Business Logic without Connectivity. They all need to be present in order to produce meaningful functionality. But this will only happen when all groups finish their part, and only then they will have a fair chance of seeing how those parts work out together. And guess what happens when proper integration only occurs at the end? A lot of things suddenly are wrong, a lot of assumptions that were made by those groups turn out to be incorrect and there is a lot of rework ahead. This always happens when work is split by architectural components or skill areas, for example. 

A better approach

A much better way would be to split work by value. So, instead of going component by component, we take a different approach. Assuming that a feature entails a number of user scenarios, we just pick one such scenario—maybe the simplest, most straightforward success scenario for the user. So, if the feature was, for instance, order management, we’re going to carve out a chunk that simply allows the user to create an order. They cannot update it yet, they cannot cancel it, they cannot change the shipment info, and so forth, but just create a simple order with default settings. But this chunk will include work in all the layers: UI, business logic, connectivity, and database. And once this chunk is finished, it can be integrated. So, if we made some incorrect assumptions about how the database structure will work with our UI paradigm, we will see it, very early, as soon as this first slice is done. 

But even more importantly, the first slice—even though it may not be deliverable to the customer—it can be demonstrated to them to get some feedback, to see if it makes sense. And it may turn out—as it often does—that there’s a better way to go about certain aspects of order management. But we learned about it early and now we can leverage that learning when implementing the rest of the functionality. And of course, we want to slice the rest of it in a similar way, by the remaining scenarios, for instance. 

In summary, we want to split work in such a way that each slice represents customer value. This is one of those fundamental skills for every team, every product owner, every product manager. And at first, it always seems impossible; but that’s mostly because of the established habits of splitting work, that grow so deep in our perception of effort that after a certain point we can’t even think differently. And this has to be very carefully and systemically addressed. 

Taking action

Alright, here comes an important question: How is work split in your environment? Is it split by value? If it is not, you must help instilling this new and important way of dealing with complex effort. So, plan one concrete step in that direction. 



Learn more

Gojko Adzic, Splitting user stories -- the hamburger method,

Bill Wake, Twenty Ways to Split Stories,

ScaledAgileFramework®, Features and Capabilities,

Alex Yakyma, Pursuing Enterprise Outcomes: Maximizing Business Value and Improving Strategy for Organizations and Teams (Aug, 2020), Chapter 6

Alex Yakyma

Alex Yakyma is the author of “Pursuing Enterprise Outcomes” and “The Rollout”. As a consultant, Alex is helping enterprises succeed with complex challenges. Throughout his career, he operated in multi-cultural, highly distributed environments. Alex has trained a large number of change agents and leaders whose key role is to help their organizations achieve higher effectiveness at pursuing business outcomes.

Explore more content

Improving in the moment

Seeing the opportunity
Read more

Being an Agile developer

Knowledge workers are key to Agile <
Read more

Unit and Integration Testing Overview

The two important types of testing <
Read more
Contact Us