Scrum does not support parallel development of features.
Not because it forbids it. Anyone can split a team across two features. It’s that Scrum gives the team no way to know whether the split is safe.
The sprint is the result. When you can’t coordinate on structure, you coordinate on time.
What Scrum Assumes
Scrum assumes no design. Requirements go to the dev team, and the team is asked to finish them within a sprint. Nothing in the framework says the system must be decomposed first, or that the pieces must be defined, or that the relationships between them must be known.
Scrum also assumes no schedule. There’s no dependency model, no critical path, no work order. The team receives a set of stories and a calendar boundary.
These aren’t oversights. They’re the framework’s starting conditions.
What Follows From Those Assumptions
Without a design, the team doesn’t know how the work divides.
Without a schedule, the team doesn’t know what depends on what.
Without dependencies, the team can’t tell whether two features can proceed side by side — or whether one is quietly blocking the other.
And without that, the team can’t tell whether it’s ahead or behind. A burn-down chart shows story points consumed. It doesn’t show which critical path is about to jam. It can’t — there is no critical path to show.
So the team faces a problem: it must make progress, but it can’t see what will block it. The only boundary it can see is the sprint’s end.
The Rational Response
Given that, the rational move is to consume story points as early as possible. If you can’t tell what’s about to block you, you minimize the risk of running out of time by burning work as fast as you can.
That means everyone works on the same bag of stories. Not because Scrum requires it, but because splitting up is unverifiable. A sub-team on feature B might be blocking feature A — and without a dependency model, no one can tell.
So the team can’t say: two members work on feature A, one member works on feature B. It can’t say: this path is about to jam, so let me work on something else and return later. It has no basis for either decision.
Everyone stays on the shared backlog. Everyone burns points together.
Why This Forces the Sprint
Real work doesn’t divide that way.
Skill distribution means a specific sub-team may need to stay on one feature for a long stretch. The rest of the team will wait for them. And that waiting produces exactly the pressure the sprint then measures: the work gets squeezed at the boundary, and the team is judged on whether the points were consumed.
So a Scrum team avoids parallel development. It squeezes different stories into a sprint and treats them as structurally coherent — when they often aren’t.
What the Sprint Actually Is
The sprint isn’t a design choice. It’s the consequence of a missing one.
A framework without design and without a schedule has no axis to coordinate on. No dependency model, no critical path, no work order. Structure would be an axis. Dependencies would be an axis. Time is what’s left.
So the sprint isn’t a feature of Scrum. It’s what Scrum produces when it has nothing else to schedule against.
That’s why the designers of the Scrum framework built it. Not because two weeks is optimal, but because a calendar is the only boundary available when the structure is unknown.
What’s Missing
Three things, in order.
A design. The system divided into components, with owners and boundaries. This is what makes the work divisible — and what makes parallel development verifiable instead of a guess.
A dependency model. What must be true before what. This is what turns “can we split up?” from a guess into a decision.
A schedule plotted from both. Dates that come from the dependencies, not from past velocity. Critical paths that are visible before they jam, not after.
With those three, a team can run multiple features in parallel. It can move someone off a blocked path and back later. It can commit to a date without guessing. None of that requires a sprint — and none of it is available in Scrum.
Albatross starts where Scrum stops: structure designed before construction, dependencies made explicit, and a plan that doesn’t reset at a calendar boundary. The sprint isn’t needed, because the thing it was substituting for is actually there.
Related: