Why progressive scope delivery is simplicity in practice
We had a component feature that needed rounded corners. All four corners, per the design comp. The design was clear, the stakeholders had approved it, and the development team was ready to build.
So we shipped two corners.
Top left and top right. That’s it. Bottom corners got deferred to a separate iteration. And the team moved on to the next priority.
If that sounds like we cut corners — pun fully intended — let me explain the thinking. The rounded corners feature had two distinct levels of complexity. The top corners were straightforward: apply a border-radius to the top of the component, match the value from a related component in the design system, done. The bottom corners, though, interacted with a background layer that used a different rendering approach. Getting those bottom corners right meant solving an architectural question about how component layers stack — a question that affected more than just this one feature.
We could have held the entire feature until both halves were ready. That would have been the “complete” approach. But completing the bottom corners would have meant blocking a release for an architectural conversation that deserved its own space and its own timeline. Meanwhile, the top corners were ready, tested, and delivering value.
One of our guiding principles at Johns & Taylor is Simplicity — use the right tool, not the clever one. And in scope management, the simplest approach is almost always to find the smallest thing that ships value and ship it. Not because you’re being lazy. Because you’re being honest about complexity.
I’ve watched teams tie themselves in knots trying to deliver “complete” features. They bundle the straightforward parts with the hard parts, and the hard parts become blockers that prevent everything from shipping. Three sprints go by. Stakeholders start asking uncomfortable questions. The team is demoralized because they’ve been working hard but have nothing to show for it. And the straightforward parts — the ones that were ready weeks ago — are sitting in a branch gathering dust.
Progressive scope delivery means recognizing that most features can be decomposed into independently valuable increments. The question to ask during story refinement is: “Can this be split into a smaller shippable unit?” If the answer is yes, split it. If the answer is “but the stakeholder wants the whole thing,” then you have a conversation about sequencing, not scope.
This approach actually respects the stakeholder more than the “deliver everything at once” approach. When you ship the top corners, the stakeholder sees progress. They can evaluate the direction. They can provide feedback before you’ve committed to the full implementation. And if the architectural conversation about the bottom corners reveals that the original design needs adjustment — which happens more often than anyone likes to admit — you haven’t wasted effort building to a spec that’s about to change.
We applied this same principle when we encountered a complex global footer component on the same platform. Early estimates suggested it might need an entire sprint just for the implementation approach — before any actual building began. Rather than pretending we could squeeze it into a release alongside other features, we flagged the complexity early and gave it the space it needed. The other features shipped on schedule. The footer got the architectural attention it deserved. Nobody was a hero, and nobody was a bottleneck.
The pattern I see in teams that struggle with delivery isn’t a lack of talent or effort. It’s an inability to decompose. They see a feature as a monolith — something that either ships whole or doesn’t ship at all. Progressive scope delivery treats every feature as a sequence of increments, each one delivering value, each one informing the next.
There’s a discipline to this that doesn’t come naturally. It requires someone to look at a feature spec and say, “What’s the smallest version of this that’s worth shipping?” That’s an uncomfortable question because it forces you to prioritize ruthlessly. The bottom corners aren’t unimportant. They’re just not as important as shipping the top corners now and learning from them.
Simplicity doesn’t mean doing less. It means doing the right amount at the right time. Ship what’s ready. Learn from it. Ship the rest when it’s ready, too.
Top corners first.
