The Sweet Illusion of a Feature Sprint

In every development cycle, there’s a moment of clarity—a fresh feature, well-defined, ready to be built. At the start, it looks simple, digestible. A piece of cake.

As engineers dive in, that cake gets eaten. Each commit, each pull request, each problem solved takes a bite out of it. The cake fuels progress.

But then, as the sprint ends, there’s always the same question: what happens to the leftover cake?

The Leftover Cake Problem

Inevitably, some work doesn’t get finished. Bugs appear, scope shifts, unexpected complexity sneaks in. At the end of the sprint, there aren’t just crumbs left—there are chunks of cake sitting on the table.

It’s tempting to treat these leftovers as something we can just roll over into the next sprint. After all, we started it, so we should finish it, right?

Wrong. There is no cake.

Why Leftovers Don’t Work

Leftover work isn’t just unfinished tasks—it’s a sign that something needs to be reshaped. Carrying it over without reshaping it is like serving a half-eaten cake as dessert in a Michelin-starred restaurant.

(Though, to be fair, that might actually be considered avant-garde?)

Here’s why that doesn’t work:

1. The context has changed.

By the time a sprint ends, the conditions that shaped the original plan may no longer be relevant. Priorities shift, new insights emerge, and what seemed essential last week might no longer be the best use of time. Simply continuing where we left off ignores the reality that product development is always evolving.

2. The cake was designed for the previous sprint.

Each feature is scoped to fit within the team’s appetite—the amount of time and effort the team was willing to invest in it that sprint. If work didn’t get finished, it means the original plan didn’t hold up—maybe the scope was too large, the complexity was underestimated, or priorities shifted mid-sprint.

But sprints aren’t just arbitrary time blocks; they are about how work is framed and approached. The feature was designed with that sprint’s appetite in mind. Carrying over unfinished work without reshaping it is like forcing old plans into new constraints—it doesn’t fit cleanly. Instead, we need to reassess, break it down differently, and ensure it aligns with the next sprint’s realities.

3. Rolling over leftovers disrupts focus.

A new sprint should start clean, with a well-defined scope and clear priorities. If we begin by carrying over unfinished work, the team isn’t fully committing to the sprint plan—they’re balancing old tasks with new ones, splitting focus between past decisions and current needs.

This creates three problems:

• Context switching: Engineers have to recall previous trade-offs and decisions while simultaneously working on new priorities.
• Unclear ownership: Does the leftover work still belong to the same engineers, or does it get reassigned? This can lead to delays and misalignment.
• Scope creep: If a task wasn’t completed in the previous sprint, it’s likely more complex than expected. Dropping it into the new sprint without reshaping it risks inflating the workload and making timelines unpredictable.

Instead of carrying over unfinished work, we need to step back and reshape it—treating it as a new problem, not just a task to complete.

So, How Do We Eat the Cake?

If leftovers don’t carry over, that means the way we consume the cake during the sprint matters even more. How engineers break down and deliver features can make the difference between a smooth sprint and one that ends in rushed, unfinished work.

The best approach? Make sure every bite is complete and satisfying.

How to Slice the Cake: Vertical, Not Horizontal

If every sprint starts with a fresh cake, then the way engineers take bites out of it matters. Not all slices are created equal.

The best way to slice a feature is vertically—building something that works end-to-end, even if it’s small. A vertical slice delivers a complete, usable piece of functionality that customers can see and react to.

Why Vertical Slices Work Best

1. Faster Feedback: Shipping something that works—even in a basic form—allows customers, stakeholders, and the team to react early. The sooner we get real-world feedback, the sooner we can refine the feature.
2. Higher Engineer Satisfaction: Completing a visible, working piece of a feature feels meaningful. Engineers can see their progress, reducing the frustration of working on backend logic that doesn’t immediately result in something tangible.
3. Avoiding the “One-Layer-at-a-Time” Problem: If engineers only work on isolated layers (e.g., all backend first, then frontend later), there’s a risk that nothing is actually usable until the very end. That increases the chances of last-minute surprises, rework, and rushed decision-making.

Bad Slicing: Eating One Layer at a Time

A multi-layered cake is meant to be eaten as a full bite, where all the flavours—frosting, sponge, filling—come together. No one eats an entire layer of frosting first, then moves to the cake, then finally gets to the filling. That would be a terrible experience.

(I’m sure some of you eat your cake layer by layer and, for some reason, derive pleasure from it. No judgment—live your best life.)

Yet, teams sometimes approach development this way—splitting the work into horizontal layers where backend engineers build all the data models first, API engineers work on endpoints later, and frontend engineers implement the UI last. The problem? None of these pieces alone deliver value.

At best, the team doesn’t see results until late in the sprint. At worst, the layers don’t fit together as expected, leading to last-minute chaos. Horizontal slicing also means engineers spend days or weeks working on something that isn’t useful yet, which can feel demotivating.

A better approach is to take vertical bites as a team—delivering end-to-end functionality in small, usable increments. This doesn’t mean every engineer has to be full-stack, but it does mean that each person’s contribution should push the feature forward in a way that results in something functional. A backend engineer might set up the data model while also exposing a minimal API that a frontend engineer can immediately use to wire up a simple version of the UI. This way, there’s always something testable, demoable, and usable.

The Right Mindset: Full Bites, Not Single Layers

A well-structured sprint should feel like eating cake the right way—each bite should contain a little of everything. That way, you know the flavours work together, you don’t have surprises at the end, and the experience is satisfying from the start.

By slicing features vertically, engineers ensure that every bite is meaningful, and teams avoid the trap of half-built work that never quite comes together.

No Half-Eaten Cake

In this methodology, we don’t do endless backlogs or endless carryovers. If something didn’t get done, it’s a signal to reassess—not a reason to mindlessly push it forward.

Each sprint gets its own fresh slice of cake. No stale leftovers. No forcing unfinished work into a new timeline where it doesn’t belong.

Because at the start of every sprint, there is no cake. There’s only a new opportunity to build something great.

At Aampe, we’ve adopted this methodology from Basecamp’s Shape Up book. If you’re interested in learning more about how to shape work effectively, we warmly recommend reading it “cover to cover”: Shape Up (Basecamp).

‍

Thanks to Rajat Goyal, whom we just onboarded to the team, who helped develop the cake metaphor.