# Micro-sprints

> **What you will learn**
> How far down to split work, why independence matters more than size, and what
> "breaking dependencies" actually means.

## Atomic units of intent

Split work down to **units that cannot be split further.**

```
✗ "Member management"                    ← a feature
✓ "Add a profile photo upload button"    ← atomic
✓ "Send the password reset email"        ← atomic
✓ "Mask personal data on account deletion" ← atomic
```

Each is **one sprint.** It can finish in minutes.

## The point is independence, not size

Confusion arises here. **"So we just cut the backlog finer?"**

Splitting alone is not enough. If the pieces **depend on each other**, you still
process them in order and get no parallelism.

```mermaid
graph TD
  subgraph "Split but dependent"
    A1["1. Change the DB schema"] --> A2["2. Update the API"]
    A2 --> A3["3. Wire up the screen"]
  end
  subgraph "Independent"
    B1["Photo upload"]
    B2["Password reset"]
    B3["Deletion masking"]
  end
```

The left has three pieces but **they stand in a line.** 2 cannot start until 1
finishes. Splitting achieved nothing.

The right does not wait on itself. **They run simultaneously.**

## What independence buys you

| Property | Result |
|---|---|
| **Parallel execution** | nothing waits, so ten at once |
| **Small blast radius** | one wrong means only that one redone |
| **Zero wait time** | no reason for everyone to gather at a sprint boundary |
| **Clean context** | each keeps [only its own context](/guide/ai-context-window) |

The last matters a lot in practice. Hand over one large job whole and the
context fills and consistency breaks; split into atomic units and each starts
clean.

## What breaking dependencies means

So what about work that genuinely has an order, like "DB schema → API → screen"?

Three approaches.

### 1. Cut vertically

Do not cut by layer — **cut by feature.**

```
✗ Horizontal: [all DB work] → [all API work] → [all screen work]
✓ Vertical:   [photo upload: DB+API+screen] · [password: DB+API+screen]
```

Each piece **goes all the way on its own.** Nothing waits.

### 2. Fix the contract first

If you really must divide, **settle the boundary first.**

```
Step 1: fix the API response format (this finishes quickly)
Step 2: backend and frontend both work against that format simultaneously
```

With the format fixed, neither has to wait for the other.

### 3. Accept it when order is genuinely required

Do not force it. Some work — a migration, say — **is inherently sequential.**
Bundle that as one micro-sprint.

> **Do not try to make everything parallel.** The goal is to parallelise what
> can be parallel, not to split things by force.

## The practical test

Put the work in front of you and ask:

```
□ Can this be completed on its own?
□ Can this be tested on its own?
□ Can this be deployed on its own?
□ Does it need another task to finish first?  ← yes means it is not split yet
```

**The third (deployed on its own) is the strongest test.** If it can be deployed
separately it is definitely independent.

## A feel for size

| If it | Verdict |
|---|---|
| Fits in one sentence | about right |
| Contains an "and" | still too big. Split it |
| Can be expressed in 2–3 tests | about right |
| Involves several teams | too big |

**"And" is the signal.** "Upload the photo and generate a thumbnail" is two
things.

## Common misconceptions

### "Won't splitting this finely make management harder?"

If people manage it, yes. Tracking ten sprints by hand is a job in itself. **But
automate the tracking and the count stops mattering.** Atomic units become
viable precisely because management cost fell.

### "Won't we lose the big picture?"

The big picture lives in **the intent.** Micro-sprints are a unit of execution,
not a unit of planning. The goal "improve member management" stays intact; only
the execution is atomic.

---

## Check yourself

**1. Why is cutting the backlog finer not enough on its own?**

<details>
<summary>Answer</summary>

**Because if the pieces depend on each other you still process them in order.**
Three pieces standing in a line give no parallelism. Independence, not size, is
the point.
</details>

**2. What does "cut vertically, not horizontally" mean?**

<details>
<summary>Answer</summary>

Do not cut by layer (DB / API / screen) — **cut by feature.** When "photo upload"
goes on its own from the database to the screen, it does not wait on other work.
</details>

**3. What is the strongest test of independence?**

<details>
<summary>Answer</summary>

**Whether it can be deployed on its own.** If it can be completed, tested, and
deployed separately, it is definitely independent.
</details>

---

Now do it on your own backlog. A forty-minute exercise →
[Try splitting your own backlog](/guide/ha-try-splitting)