I started four implementation slices in parallel because the tooling finally made that possible. Review environments could be created and torn down per branch, the lifecycle had explicit artifacts, and the framework conventions were enforced at commit time.

The capacity the tooling freed went into four branches rather than into smaller slice boundaries. The branches moved quickly for the first two weeks, and then the queue in front of me stopped clearing. The slices were too large, too dependent on each other, and each one contained several features that had never been named separately, so the remaining work was sequencing, review, imports, and rework.

The Failure Is Older Than The Tooling

Oversized work packages, hidden dependencies, design review arriving after scope lock, uncounted integration work, and branches that are harder to merge than they were to open are all standard decomposition failures. What changed is the cost of starting. Previously, the effort of opening four parallel workstreams was itself a filter: it took long enough that the dependencies between them usually became visible before much code existed. When a slice can be opened, scaffolded, and pushed to its own review environment in an afternoon, that filter disappears. Four slices reach the review queue in the time one used to, and the decomposition mistakes arrive with them.

The Calibration Number

The first slice on this project was documented at 66 hours. Once implementation, design review, hidden data work, framework setup, security hardening, infrastructure, and remediation were counted, the same slice modelled closer to 226 hours of traditional effort. The estimate had captured roughly 29% of the work that the slice actually contained.

The Categories The Slice Method Could Not See

The five-field slice method asked about UI, entities, routes, security scope, and done criteria. Six categories of delivery work fell outside those five fields.

  • Import. Estimated at zero, because it lived in a side document with no hours attached. It became roughly 45 hours: a sync engine of about 1,200 lines, several import passes, well over 100,000 reference records seeded from external authorities, and tens of thousands of redirects.
  • Framework and toolchain integration. The work of making the slice run inside the project's build, test, and dependency setup, which no field in the method asked about.
  • Security hardening. Carried as a single three-hour line for one editor role. The real figure was around ten hours once the access rules met actual data.
  • Review-environment infrastructure. About twelve hours of deployment work with no line item at all. None of the five fields asked where the slice would be deployed for review.
  • Design review after scope lock. Scope was locked, then a later design pass added about 75 hours and forced rework. One navigation was built, removed, and replaced, so it was paid for twice.
  • Review remediation. A recurring round of correction commits after each review pass, which nobody had budgeted as work.

Why Parallel Slices Amplify Each Category

Across four concurrent slices each of these six categories is shared. One import assumption sits underneath several branches, so when it turns out to be wrong the correction lands in all of them, and the branches that were waiting cannot proceed until it does. One design reversal invalidates dependent interface work in whichever branches consumed the old layout. A gap in review-environment infrastructure serialises review. A security pattern discovered in the third slice has to be applied back across the other three, in three separate diffs, each needing its own review.

What "Make Smaller Slices" Leaves Out

The obvious correction is to slice smaller. As an instruction it is close to useless, because it contains no way to tell whether a given slice is too big while there is still time to act. The estimate said 66 hours in a document that was internally consistent. The failure was only visible in the commit history afterwards. That history holds five signals worth naming.

Churn multiplier is the total lines written across a slice divided by the lines that survive in its final diff. A slice near 1.0 kept what it wrote. Above that, the same files were written, reversed, and written again inside a task that had already been counted once, which is why this rework never appears as additional hours.

Fix-like commit share is the proportion of a slice's commits that correct earlier commits in the same slice rather than adding capability. When that share is high, the slice was being repaired while it was still being built, which usually means it was never reviewable in parts.

Files touched repeatedly counts files edited five or more times within one slice. Each repeated edit marks a seam, a boundary renegotiated during implementation, most often because two features that should have been separate were sharing a file.

Named-feature share asks how much of the diff belongs to the feature the slice is named after. In one of these slices the feature interface came to about 400 lines out of 7,647. Around 5% of the slice was the thing the slice was called. The remainder was infrastructure, migration, and tooling, with no name and no estimate anywhere in the plan.

Stacked-branch deltas matter because these branches were stacked rather than independent. When one branch is based on another, its diff against the trunk contains its parents' work, so measuring naively counts the same code several times. Each slice has to be measured as its own isolated delta, from its base to its tip.

Applied to the first slices, one of them showed 57% of its commits doing fix-like work on a branch that was being reported as progressing.

Every one of these five reads the commit history, which means all of them arrive after the slice has been built and merged. The next article is about turning them into thresholds that fire while a slice is open, and about the re-slicing pass that takes an oversized branch and emits the smaller slices it should have been.