April 11, 2023
Tackle big ideas: Break work down
One of our software teams was talking about user stories the other day, specifically about splitting them to make them smaller and more manageable.
Following the discussion, I shared a link to a tried and true story splitting worksheet as well as a video tutorial about story splitting. Because our teams have highly visible Slack channels, Alex saw the conversation and thought “Hey, this can apply to just about anything!”.
He’s right, it isn’t just about software and user stories.
Why break work down?
Perhaps a better question is “why not”? We tend to consider breaking work down as our default approach. Here are some compelling reasons to consider doing this with your workload.
Collaboration and delegation
In Agile working, we actively seek opportunities for collaborative working. A monumental task is difficult to brief someone on; small tasks are more straightforward and quick to onboard.
![A large shape split into multiple smaller parts, with a different person pointing at each part.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e54927444dba571eec_why-1.jpeg)
Progress, satisfaction and trust
Your ability to show completed work to a stakeholder with some regularity is crucial to gaining and building trust with them. Moving smaller tasks to completion is helpful in both building a sense of progress and a feeling of satisfaction (“That is done! What’s next?”).
![A large object is shown with question marks. The same object is broken down into parts, some of which are marked as "completed". A person is looking at the completed parts from a distance.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e54927444df0571eed_why-2.jpeg)
Easier to change course
We are often working in uncertain or complex environments, which requires us to be creative and experimental. By delivering small but meaningful jobs, we can get feedback on whether we are moving in the right direction.
![A large vehicle is stuck trying to navigate a tight junction. A number smaller vehicles can easily take a turn in that junction.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e54927442d48571eee_why-3.jpeg)
Granular prioritisation
Sometimes we have a lot of ideas packed into one job. By breaking them down into their constituent elements, we can actually prioritise the important parts we want to achieve early and tackle the nice-to-haves later on.
![A scale is tilting to breaking point with a large item on one side. Another scale, with multiple smaller items on each side, is more evenly balanced.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e5492744343a571ef0_why-4.jpeg)
When should you break work down?
It may be difficult to break work down. It does take some consideration and effort. There are a few situations where breaking work down into smaller tasks is a good idea. Here are a few such situations.
There are a lot of unknowns
Your job ahead may be bigger or more complex than you think. You can drive towards gradual clarity if you break the work down into small, clear component parts.
![A ship is approaching an iceberg. The person on top of the ship can’t see how much of the iceberg is under the water.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e5492744dab7571ef4_when-1.jpeg)
You have no idea how long it might take and that fills you with dread
It has been proven that the smaller a job is, the more accurately you can estimate it, thus increasing the confidence level.
![A casino “slot machine” is showing random digits corresponding to the expected delivery date of a piece of work](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e54927441edd571eea_when-3.jpeg)
The job won’t fit into a time-boxed increment (e.g. a sprint)
Timeboxing is a useful technique to keep work in check and manage the risk of spending too much time being unproductive or moving in the wrong direction - “sprints” in Agile software development are one example of this. If you aren’t sure whether a job can be completed within a standard time boxed unit (e.g. 1 sprint), you should really try to split it.
![Material is spilling out of a partially opened box labelled “TIME”.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e5492744a556571ef6_when-2.jpeg)
You want to prove or learn some value quickly
You have an idea, but you aren’t sure how it will pan out. It’s best to get going and do something small, then seek validation from your customer or stakeholders. This ‘proving’ or ‘learning’ will help eliminate the wasteful practice of ‘building the wrong thing’.
![A person wearing a square academic cap is pointing at a screen titled “Demo” and is holding pouch full of money.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e5492744ecb3571eff_when-4.jpeg)
How to break work down
You’ll find a lot of advice specific to different domains, including the user story splitting worksheet that kick-started this article. Much of this advice could be summarised into 4 different principles - keep these in mind and you’ll have a “work breakdown mindset” that can apply to (almost) anything:
1. Carve out the beginning (or end) first
Maybe you have a complex workflow in mind. Do the simplest one first. Then later on flesh out with more complexity. An example is publishing articles. Start with Write (the beginning) and then Publish (the end). Then proceed with the middle steps: editorial changes, approvals, keeping a history of drafts, etc.
![A series of numbered boxes represent a workflow. The first and last steps in that workflow are highlighted.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e54927440a2c571ef7_how-3.jpeg)
2. Carve out a single path / use-case
Again, the aim is simplicity, and minimising effort. If there are many paths in your product usage, choose the one that is the most impactful for your customers. An example could be ways to take payment. Start with only Paypal. Then introduce credit card, then Apple Pay, etc.
![Multiple paths split out from a single starting point. A single path is highlighted as something that can be completed individually.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e5492744f640571efe_how-1.jpeg)
3. Carve out different “operations”
You may have an idea of different types of people able to do different things. Start with the experience for a single role, and nail it. Another example would be to first design and build the experience for someone to see their account information. Then, you can figure out how to allow them to edit or delete my account. These can all be distinct items you work on.
![There are multiple buttons on the front of a video cassette recorder. One of the buttons has a “coming soon” sticker attached to it.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e549274480d7571ef9_how-4.jpeg)
4. Carve out a non-optimised path
Avoid the risk around over-engineering. You may find yourself spending loads of time working on something the customer doesn’t even need or use. Before you decide to invest time in a fully optimised version of something, consider what other paths you can take to achieve the end result, even if they seem less elegant.
![A mountain stands in the middle of a tarmac road leading to a pot of gold under a rainbow. There’s space for a tunnel to go through the mountain but it’s not yet built. A bicycle is following a slower and more convoluted dirt road around the mountain to get to the pot of gold.](https://cdn.prod.website-files.com/643589e549274436c4571d86/643589e54927441f36571efa_how-2.jpeg)
Break work down, it makes work better
If you are planning something big, consider this metaphor: Start with boulders. As you start to plan in the short term, break them down into rocks. When you’re about to start working on something, be thinking in terms of pebbles and granules.
At Reason, we like the idea of breaking work down wherever possible. No big-bang releases, no “big design up front”. De-risk your work by dealing with clear, manageable tasks.
Someone wise once said “Think big. Start small. Move quickly.” It’s a nice axiom to live by.
--
Greg Franklin is an Agile Coach at Reason. This post was co-authored with and illustrated by Alex Baxevanis, who is the Head of Experience Design.