# Try splitting your own backlog
> **What you will learn**
> Not a chapter to read but one to **do**. Take one work item you have in
> flight, split it down to atomic units, and see for yourself whether those
> units **stand in a single queue because of their dependencies.**
## What you need
```
□ 40 minutes
□ A sheet of paper or a whiteboard
□ One work item in flight — not a finished one, one you are doing now
· a few days to a few weeks in size
· something the team knows, not only you
□ Ideally with the person actually doing the work
```
**"Not a finished one" is the part that matters.** Finished work splits cleanly
because you already know how it turned out. Only live work shows you the real
dependencies.
> No suitable item? Use this one — **"Improve account deletion: capture a
> reason, mask personal data, and show deletion statistics to admins."**
---
## Step 1 — Write it as one sentence (5 min)
Write the item as **a sentence**, not a title.
```
✗ "Account management improvements" ← a title
✓ "Capture a reason on deletion and mask personal data" ← a sentence
```
### What to look for
```
□ Does it contain "and"?
□ Does a comma join two separate actions?
```
**If either is true it is already more than one item.** That is the raw material
for step 2.
---
## Step 2 — Cut at the conjunctions (10 min)
Split at the conjunctions and make a list. **You should end up with four or
more lines.**
| # | Atomic unit | Fits in one sentence? |
|---|---|---|
| 1 | | |
| 2 | | |
| 3 | | |
| 4 | | |
| 5 | | |
```
The example item, split:
1. Add a reason picker to the deletion screen
2. Mask name and contact details on deletion
3. Create somewhere to store the deletion reason
4. Show deletion-reason statistics on the admin screen
5. Send a deletion confirmation email
```
**Most teams get this far easily.** The next step is where it bites.
---
## Step 3 — Draw the arrows (10 min)
**This is the point of the exercise.** Between the lines, draw an arrow wherever
"this has to finish before that can start".
```
3 ──→ 1 (there must be somewhere to store it before you can pick it)
3 ──→ 4 (there must be stored data before you can count it)
2 (stands alone)
5 (stands alone)
```
### What to look for
| What you drew | What it means |
|---|---|
| No arrows at all | already independent. Rare |
| **One continuous chain** | **splitting bought you nothing.** Go to step 4 |
| One or two clusters | normal. Take just those to step 4 |
**The middle row is the normal outcome.** This is where most teams see that "we
thought we had split it, but it was one queue all along" — the claim that
[splitting alone is not enough](/guide/ha-micro-sprint), verified on paper.
---
## Step 4 — Re-cut vertically (10 min)
Take whatever the arrows tied together and cut it again **by feature, not by
layer.**
```
[Cut by layer — arrows appear]
3. create storage → 1. let them pick it → 4. show the statistics
[Re-cut by feature — each one runs to completion alone]
A. Capture the reason : storage + screen + saving, as one piece
B. Show the statistics : reads what A created and renders it
```
An arrow still remains between A and B. When that happens, **fix the contract
first.**
```
Step 0 (5 min): decide only where and in what shape the reason is stored
Then : A and B in parallel
```
**Fix the shape first and the rest becomes parallel.** Those five minutes buy
you days.
---
## Step 5 — Judge by deployment (5 min)
The final gate. Ask each piece one question.
```
□ Could you ship this one alone without breaking anything?
```
| Answer | Verdict |
|---|---|
| Yes | ✓ it is atomic |
| "Something else has to ship first" | still tied. Back to step 4 |
| "It ships, but the screen is half-finished" | **put it behind a switch and ship it off** |
**The third row is the trick.** The constraint "you cannot ship something
unfinished" creates half of all dependencies. If you can ship it switched off,
that half disappears.
---
## Self-check
```
□ The original item split into four or more
□ Arrows actually appeared in step 3 ← if none did, you cut too coarsely
□ You removed at least one arrow
□ Every remaining arrow can be explained as inherently sequential
```
If the third is unchecked, go back to step 4. **If you could not remove a single
arrow, either the work is genuinely sequential or you are still cutting by
layer.**
---
## Check yourself
**1. What does it mean if step 3 produces one continuous chain?**
Answer
**That splitting bought you nothing.** Five pieces in a queue still have to be
worked through in order, so no parallelism appears. The point of a micro-sprint
is independence, not size.
**2. Explain "cut vertically" using this exercise.**
Answer
Storage → screen → statistics is a cut **by layer**, and each waits on the last.
Cutting **by feature** — "capture the reason" running from storage through to
the screen on its own — means it waits for nothing.
**3. Why does "it ships, but the screen is half-finished" count as independent?**
Answer
**Because you can ship it behind a switch, turned off.** The constraint that
unfinished work cannot ship creates a large share of all dependencies, and
shipping it switched off removes that constraint.
---
Next: what a developer's output turns into → [IntentOps](/guide/ha-intentops)