HyperTeamsMicro-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.
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.
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"]
endThe 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 |
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.
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.
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:
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?
Answer
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.
2. What does "cut vertically, not horizontally" mean?
Answer
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.
3. What is the strongest test of independence?
Answer
Whether it can be deployed on its own. If it can be completed, tested, and deployed separately, it is definitely independent.
Now do it on your own backlog. A forty-minute exercise → Try splitting your own backlog