Case Study // Delivery Governance Capacity Protection + Sprint Architecture

Web Experience
Capacity
Expansion

Two product owners and two designers feeding a 159-page backend system through 1.25 FTE of engineering capacity. No intake filter. No scope governance. No delivery cadence. The senior engineer was the only person who understood the data paths... and he was spending a third of his time training a junior. This wasn't a staffing problem. It was a structural one. The team needed a capacity protection system before it needed a single new feature.

Frameworks
& Artifacts

The diagnostic produced one primary artifact: a role-weighted capacity assessment that mapped upstream production volume against bottleneck execution capacity.

No Process Could
Protect the Bottleneck

The web experience team was seven people: two product owners, two UX designers, an analyst, a senior full-stack engineer and a junior front-end developer. On paper, a reasonable roster. In practice, a structural mismatch.

The two product owners and two designers generated scope continuously... wireframes, user stories, research findings, feature requests. All of it funneled toward engineering for execution. But the senior engineer was the only person who understood the backend data paths through a 159-page manual fulfillment system. Every feature, every fix, every integration had to pass through him. The junior developer was learning, but that learning consumed roughly a third of the senior engineer's available bandwidth.

Effective engineering capacity: 1.25 FTE. Upstream production capacity: 4 FTE.

Then there was the founder layer. New requests appeared without warning, reprioritized by executive attention span rather than roadmap logic. Features that weren't on any sprint plan would land in the engineering queue because leadership got excited about a shiny object. Whatever informal prioritization the team had built was regularly overridden from above.

There was no intake filter. No Definition of Ready. No sprint cadence to create predictable delivery windows. No mechanism to say 'not this sprint' to anyone... including leadership.

The senior engineer was burning out. The design queue was growing faster than code shipped. And the team had no structural defense against any of it.

What the
Diagnostic Found

The capacity assessment surfaced seven structural constraints. None of them were about talent or effort. All of them were about how work flowed (or didn't) through the team.

Red
Single Point of Failure on Backend Logic
The senior engineer was the only person who could map features to the 159-page fulfillment system. If he was sick, on vacation or left the company... nothing shipped.
Red
4:1 Upstream-to-Execution Ratio
Four producers generating scope for 1.25 FTE of engineering capacity. The team was creating work three times faster than it could deliver.
Red
No Intake Filter
Stories entered the engineering queue without technical feasibility checks. Design work was completed before anyone confirmed the backend could support it.
Yellow
Executive Scope Injection
Leadership bypassed whatever informal prioritization existed to insert new requests. No mechanism to evaluate these against current sprint commitments.
Yellow
Mentorship Tax Invisible in Planning
The senior engineer's mentoring load on the junior developer was real but unaccounted for in capacity planning. Sprint commitments assumed full availability that didn't exist.
Yellow
No Definition of Ready
Stories moved to engineering without clear acceptance criteria, technical vetting or task breakdowns. Engineers spent review cycles on work that should have been filtered upstream.
Yellow
No Delivery Cadence
Work shipped on a 'when it's ready' basis. No sprint rhythm. No predictable release windows. Stakeholders had no visibility into when anything would land.

Building the Machine
That Could Say No

The intervention wasn't a reorganization or a new hire. It was a governance layer... a set of structural filters designed to protect the engineering bottleneck from upstream overproduction and executive scope injection. Every mechanism served one purpose: make the team's actual capacity visible and non-negotiable.

Phase 01
Capacity
Diagnosis
Mapped the team by role type and production output. Calculated the real upstream-to-execution ratio. Made the mentorship tax visible in sprint planning for the first time. The 4:1 imbalance wasn't a surprise to anyone who lived it... but it had never been documented as a structural constraint.
Phase 02
Intake
Filter
Implemented a Definition of Ready with engineering veto power. No story entered the sprint backlog without a technical feasibility check signed off by the senior engineer. Design work that couldn't be mapped to the backend data paths was returned to grooming. The veto was structural, not personal.
Phase 03
Sprint
Cadence
Stood up a bi-weekly sprint cycle with six ceremonies: backlog grooming, sprint planning, async story-to-task breakdown, sprint kickoff, daily standups and stakeholder demos. Each ceremony had a single owner, a time boundary and a defined output. The cadence created predictable delivery windows that didn't exist before.
Principle
ROI as the Only
Prioritization Axis
Forced ruthless stack-ranking of the backlog by return on investment. Not executive preference. Not recency of request. Not loudness of stakeholder. The question at every grooming session was the same: given 1.25 FTE of engineering capacity this sprint, what produces the most value? Everything else waited.

What the
Governance Built

115%
Conversion Rate Lift
(20% → 43%)
160%
User Growth
122%
Session Increase
6
Ceremonies Stood Up
From Zero
5%
Rental Requests
Completed Online

The shortest version: a team that couldn't ship consistently was producing bi-weekly releases within two months. The governance model was working well enough that leadership had begun planning a handoff to a program manager... the early stages of a transition that would have tested whether the system could run without its architect. That transition never materialized. The director was fired. The team was moved to a new org.

The conversion lift, the user growth, the session increases... those happened while the capacity protection model was active. They're the output of a team that could finally prioritize by ROI instead of reacting to whoever asked last.

Back to The Warehouse