Sequence, slice, and dependencies

A team commits to a feature and does the responsible thing: it breaks the work down. Six tickets. Schema first, then the data pipeline, then the service, then the API, then the interface, then the polish. Each ticket is small, estimated, and independently reviewable. The board moves every day.

In week five, the interface is connected for the first time. Two things become visible at once. The data the pipeline produces is not the data the interface needs. And the underlying assumption about how the feature would be used was wrong in a way that anyone could have seen in a working version.

The team did not fail to break the work down. It broke the work down along the architecture instead of along the uncertainty. Every ticket was smaller. No ticket was a slice. Nothing finished early could be shown to anyone, tested against reality, or kept if the project stopped. All the learning and all the integration risk was stacked into the final week, which is exactly where the team had the least room to respond.

This is hard to see from inside because it looks like good practice. The tickets are small. The estimates are tight. Velocity is stable. The measurement system reports health right up until the week it does not.

The mechanism is that breaking work down along the architecture pushes every moment of contact with reality to the same place — the end:

flowchart LR
  W["Work split by<br/>architecture layer"] --> T["Six small tickets<br/>board moves daily"]
  T --> S["Nothing runs<br/>end to end"]
  S --> F["Week five<br/>first connection"]
  F -->|"integration risk<br/>arrives here"| I["Pipeline output ≠<br/>interface input"]
  F -->|"usage risk<br/>arrives here"| U["Core assumption<br/>was wrong"]
  I --> L["Both land where the team<br/>has least room to respond"]
  U --> L

Ask about the next piece of work your team plans to finish: if we stopped immediately after this piece, what would we have that is worth keeping, and what would we know that we do not know now? If the answer to both is "nothing", it is a smaller ticket, not a slice.

Judge every slice on four properties. A slice that fails all four is a task; a slice that satisfies at least one deliberately is a delivery decision.

Property	The question	Failed when
Evidence yield	What does finishing this let you learn that you cannot learn now?	Nothing is learnable until the whole thing exists
Option value	If you stopped here, what would you still have?	Stopping leaves partial work that must be thrown away
Integration safety	Can this reach production without exposing users?	The pieces only meet at the end, in one large merge
Dependency retirement	Which dependency or unknown does this settle?	Every dependency is still open on the last day

A sequence is not a list of slices. A sequence is an order, and the order should be driven by which uncertainty is most expensive to discover late.

Order by uncertainty, not by layer. The question is not "what has to be built first" but "what would hurt most if we learned it in the final week". Usually that is one of three things: whether the effort estimate is right, whether the integration works, or whether the thing produces the outcome you claimed.

Put the two orderings on the same clock. Noted's dependency migration is estimated at three to five weeks against ten weeks of remaining support, so the question of which ordering you chose becomes answerable in week two under one of them and week nine under the other:

timeline
  title Two orderings of one migration, against ten weeks of support
  section Ordered by layer
    Weeks 1 to 4 : Adapters and scaffolding : Nothing runs on the new dependency
    Weeks 5 to 8 : Wire the paths together : Estimate still spans three to five weeks
    Weeks 9 to 10 : First real cutover attempt : Every unknown arrives at once
  section Ordered by uncertainty
    Weeks 1 to 2 : One narrow path migrated end to end : The three-to-five spread narrows or widens
    Weeks 3 to 6 : Remaining paths, one dependency retired each : Stopping here still leaves working paths
    Weeks 7 to 8 : Rehearsed cutover with rollback : Only the indivisible moment is left

Both rows contain the same work. The lower row is not faster. It is arranged so that the most expensive thing to learn late is learned first, and so that stopping at any point leaves something worth keeping.

Three kinds of dependency

They are treated as one word and handled the same way, which is why they cause different failures.

Kind	What it means	How it is handled	Failure when misread
Sequence	B cannot start until A exists	Order the work, and shorten A	Treated as a knowledge gap and "researched" while it just needs building
Capability	You need something another team or system owns	An interface contract plus a stub you can build against	Treated as sequence, so your team waits instead of proceeding against a contract
Knowledge	You need an answer before the shape of the work is known	A bounded investigation with a decision date and a default	Treated as capability, so it is delegated and never returns

The most common error is treating a capability dependency as a sequence dependency. That converts another team's schedule into your critical path for no reason, when a written interface and a stub would have let both sides move.

Two things a slice can be for

A slice can be shaped to maximize learning, or to minimize risk. These are not the same shape and they sometimes conflict. A slice that exposes the riskiest integration first teaches you the most and is the most likely to destabilize the build. A slice that isolates the risky part behind a safe boundary is calmer and tells you less.

You do not resolve this in general. You resolve it per slice, by saying which one this slice is for. A sequence where every slice is unlabelled is a sequence where nobody can tell whether it is going well.

Boundary

This test orders work by which uncertainty is most expensive to discover late. It does not tell you whether a slice is small enough to review. That is a different question — about architectural seams and how much diff a human can hold at once — and a sequence that scores well here can still arrive as one unreviewable change.

Slicing has a floor, and below that floor it costs more than it saves.

Some work is genuinely indivisible. A cutover from one dependency to another, a schema change with no compatible intermediate state, a security patch — these have a moment where the old thing stops and the new thing starts. You can slice everything around that moment: preparation, compatibility work, verification, rehearsal, rollback readiness. You cannot slice the moment itself. Pretending you can produces dual-running complexity, and maintaining two live paths is often riskier than a well-rehearsed single switch.

The second limit: slicing does not create evidence on its own. A slice yields evidence only if someone is going to look at what it produced, with a question in mind, before the next slice starts. A team that ships thin vertical slices and reviews none of them has smaller tickets with a better name.

The third limit: this model assumes the commitment behind the work is sound. A well-sequenced delivery of an unsound commitment reaches the wrong destination sooner. Sequencing is not a substitute for DS-01.

Read the Noted case if you have not already.

Take Signal 4: a core dependency loses support in ten weeks.

Engineering estimates three to five weeks, with wide uncertainty. Two engineers want to migrate now. Two want to spread the work across the quarter. After end-of-support, security patches stop; nothing breaks immediately.

Note what the disagreement actually is. It is not a disagreement about slicing. Neither position is a sequence. "Migrate now" is a start date. "Spread it across the quarter" is the absence of an order.

Your task. Produce a delivery sequence for this migration.

1. Restate the uncertainty that is most expensive to discover late. The estimate spans three to five weeks against a ten-week horizon. Say what that spread is made of.
2. Design the first slice so that it narrows the estimate. Say exactly what you would know after it that you do not know now, and how long it may take before it has failed at its job.
3. Identify the indivisible step. Name the moment where the old dependency stops and the new one starts, and say what cannot be sliced around it.
4. Write the full sequence. For each slice, state its evidence yield, its option value if the work stopped there, its integration safety, and the dependency it retires. Mark each slice as learning-shaped or risk-shaped.
5. Classify every dependency as sequence, capability, or knowledge, and give each one the handling its kind requires.
6. Compute the last responsible start date: the date after which "spread it across the quarter" is no longer available, using the upper estimate and not the lower one. State what happens on that date if nothing has started.
7. State what this sequence protects, and what it deliberately does not protect.

Step 2 is the one that separates a sequence from a schedule. Two versions of a first slice for this migration, both of which a competent engineer would accept:

The difference is not effort or seniority. The weak slice moves the work forward. The strong slice moves the estimate, which is the uncertainty that end-of-support in ten weeks makes expensive.

Expect to be pushed on: whether your first slice actually narrows the three- to-five-week spread or merely begins work; whether your slices are architecture layers wearing vertical names; and whether your last responsible start date was computed from the estimate you want or the estimate you have.

Committed to a position? Check it against what a strong answer holds

• The most expensive late discovery named first — what the three-to-five-week spread is made of — before any slice is written.
• A first slice that moves the estimate, with a sentence on what you will know after it that you do not know now, and a limit on how long it may run before it has failed at that job.
• The indivisible cutover moment identified, with a plain refusal to slice it and a list of what can be sliced around it.
• Every slice labelled learning-shaped or risk-shaped and scored on all four properties, with dependencies sorted into sequence, capability, or knowledge and handled accordingly.
• A last responsible start date computed from five weeks, not three, with what happens on that date if nothing has started.
• The most common weak move is a first slice that produces a plan or an audit. It is weak because nothing ran, so the estimate is exactly as wide afterwards as it was before.

Produce artifacts/DS-02-delivery-sequence.md using the template below.

Write it for the engineers who will execute it and for the person who will have to decide, mid-way, whether to continue. It should be legible to someone who joins in week three and needs to know what has been settled and what has not.

In your Product Decision Case, this is the first artifact that constrains other people's days. The DS-01 brief said what you would do. This says in what order, and therefore what you will know and when. DS-03 will ask who owns each of those handoffs.

# Delivery sequence · <commitment name>

- **Date:** <YYYY-MM-DD>
- **Commitment this serves:** <link or name of the DS-01 brief>
- **Sequence owner:** <person>
- **Horizon:** <period>

## Most expensive late discovery

<The one thing that would hurt most if you learned it in the final week, and
what it is made of. If your estimate has a spread, say what the spread is made
of — not how wide it is.>

## Indivisible step

<The moment that cannot be sliced: a cutover, an incompatible schema change, a
switch. Name what can be sliced around it — preparation, compatibility,
verification, rehearsal, rollback readiness — and what cannot. Write "none" only
if you have looked for it.>

## The sequence

| # | Slice | Shaped for (learning / risk) | Evidence yield | Option value if stopped here | Integration safety | Dependency retired |
|---|---|---|---|---|---|---|
| 1 | <slice> | <learning or risk> | <what you will know that you do not know now> | <what you keep> | <can it merge and run without exposing users> | <which one> |
| 2 | <slice> | <learning or risk> | <...> | <...> | <...> | <...> |

<Every slice must have a non-empty answer in at least one of the evidence-yield
or option-value columns. A slice that is empty in both is a task; either reshape
it or fold it into a neighbour.>

## Dependencies

| Dependency | Kind (sequence / capability / knowledge) | Owned by | Handling | Decision date | Default if the date passes |
|---|---|---|---|---|---|
| <dependency> | <kind> | <team or person> | <order it / contract plus stub / bounded investigation> | <date or n/a> | <what happens automatically> |

<Every knowledge dependency needs a decision date and a default. A knowledge
dependency without a default becomes an open question that follows the project
to the last week.>

## Last responsible start date

- **Date:** <YYYY-MM-DD>
- **Computed from:** <the upper estimate, the hard horizon, and the buffer —
  show the arithmetic, not just the conclusion>
- **What happens on that date if nothing has started:** <the automatic
  consequence, and who is told>

## What this sequence protects

<What the order is buying you: an earlier disconfirmation, a preserved option, a
contained integration risk. One or two sentences.>

## What it does not protect

<What you accepted in exchange. Every sequence trades something. Name it, so the
person reading this in week three does not think it was an oversight.>

## Review points

| After slice | Question to answer | Who reads it | What could change as a result |
|---|---|---|---|
| <#> | <question> | <person> | <scope, order, or the commitment itself> |

## Gaps

<Everything marked `<unknown>` above, listed as open questions with who could
close them and by when.>