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.

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?”).

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.

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.

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.

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.

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.

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’.

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.

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.

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.

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.

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.

‍