Why we ship in two-week iterations

We ship in two-week iterations. Not because Agile says we should, not because we have a sprint poster on the wall. We ship in two weeks because that's the longest interval at which a team can still credibly answer the question: did we build the right thing?

Anything longer and the feedback signal degrades. The customer who would have told you "this isn't what we needed" has moved on to another tab in their week. The engineer who knew that one approach wouldn't work has rationalized the half-built version they finished while waiting for review. Decisions accrete. The sunk-cost calculus rotates in favor of finishing whatever's in progress.

Two weeks is also short enough that the cost of being wrong is bounded. If we get to the end of an iteration and the product manager looks at the demo and says "no, that's not it" — well, the cost of that "no" is two weeks of one team's time. That's a number we can pay. A number we can pay every iteration if we have to.

What it actually looks like

Each iteration starts with a kickoff. The team — engineers, designer, product — agrees on the one thing this iteration produces. Not a list of stories, not a backlog. One thing, written in plain language: "By the end of these two weeks, a logged-in user can upload a CSV and see it processed within five minutes."

That thing has to be demonstrable. If the engineer's answer to "what did you ship?" is "I refactored the auth layer," the iteration goal was wrong. Demonstrable means a real person, not on the team, can use the thing and have an opinion about it.

Mid-iteration, on the seven- or eight-day mark, we do an honest check-in. Not a status update. The question is: are we going to hit the goal? If not, what's the smallest cut we can make and still produce a demonstrable result? Better to ship a smaller version of the right thing than a full version of nothing.

End of iteration: demo, retrospective, decision about the next two weeks. The retrospective produces one change the team will try next iteration. Not a list of "things to do better." One thing.

What two weeks isn't

Two weeks isn't a permission slip to ship low quality. The bar for "demonstrable" includes "tested," "observable," and "deployable to production with one click." If your iteration ends with a feature that works on the demo laptop but isn't behind a feature flag in production, you didn't finish.

Two weeks isn't a deadline. The goal is the artifact, not the date. If the goal is "user can upload a CSV" and on day 13 the team realizes the CSV format the customer actually has is different from what was specified, the right answer is to write that down, ship a smaller subset, and re-plan. Not to ship something that lies.

Two weeks isn't right for everything. Research that requires running a model overnight doesn't fit. Refactors that span multiple services don't always fit. We adapt. But the default is two weeks, and the burden of proof is on the team that wants more time.

Why this is the longest unit we trust

Three-week iterations sound only slightly worse than two-week iterations. They're substantially worse, for one specific reason: a three-week iteration is long enough that there's a "comfortable" middle. Two weeks of fourteen workdays has no comfortable middle — you're either in the kickoff energy or in the "we have one week left, what's actually shipping" energy.

This sounds like sloganeering. It isn't. It's the single most consistent observation we've made across forty-plus engagements. Two-week iterations have urgency baked in. Three-week iterations have a "we'll catch up next week" middle that becomes a "we'll catch up the week after" end.

The real point

The real point isn't the calendar. It's that we put the team in a position where the question "are we building the right thing?" gets asked and answered every two weeks, with real evidence, in front of someone who can change the answer. Everything else — the kickoff, the check-in, the demo, the retro — is in service of that.

Most projects that fail don't fail because the team couldn't build the thing. They fail because the team built the thing for too long before finding out it was the wrong thing. Two-week iterations are the cheapest insurance policy we know against that failure mode.