How we run a two-week build sprint
Ten working days, one shippable outcome. The calendar, the roles, and the rules we hold ourselves to on every Build engagement.
Most software projects fail on the calendar before they fail in the code. Scope grows, the deadline stays, and the team ships a compromise nobody scoped. The fix is not a better estimate. It is a shorter horizon and a harder rule about what happens at the end of it.
We run Build engagements as two-week sprints. Each sprint has one outcome, one owner, and a fixed end date. Nothing rolls over by default. A partner can buy one sprint and stop, or chain six. Every sprint ends in production, so stopping is always safe.
This is the version of the playbook we hand to partners on day zero. It is short on purpose. If a rule needs a paragraph to justify it, we cut the rule.
Why two weeks
Two weeks is long enough to ship something real and short enough that a bad bet costs ten working days, not a quarter. It also matches how agents work best. A spec written on Monday is still true on the following Friday. Longer horizons drift, and drifting specs are where agents waste the most compute and humans waste the most review time.
A sprint is not a phase in a larger plan. It is the unit. Roadmaps at Entatan are lists of candidate sprints, ranked, with the top one specced and the rest one paragraph each. When a sprint ships, the next one gets specced. Nothing further out gets more than a paragraph, because it will change.
The calendar
- Day 0, before kickoff: spec agreed, repository access granted, environments provisioned, success criteria written in one sentence.
- Day 1: kickoff. We walk the spec, cut it by a third, and agree on what done means.
- Days 2 to 4: foundations. Data model, auth, deploy pipeline, and the first vertical slice in production behind a flag.
- Day 5: mid-sprint review. Working software, not slides. Scope gets cut here if it must.
- Days 6 to 8: the bulk of the feature work. Agents run overnight on well-specified tasks; humans review every morning.
- Day 9: hardening. Load test, error budgets, accessibility pass, documentation, handoff notes.
- Day 10: ship. Flag flipped, handoff recorded, next sprint proposed or a recommendation to stop.
Roles
- Sprint owner (Entatan): one engineer accountable for the outcome. Writes the spec, runs the reviews, makes the cuts.
- Partner lead: one person on your side who can say yes. Available for a fifteen-minute decision every working day.
- Agent fleet: coding agents scoped to task cards from the board. They open pull requests. They do not merge.
- Reviewer: a second Entatan engineer who reads every merged change and owns the day-nine hardening pass.
Four roles, two of them human on our side. Sprints with more people on them do not go faster. They go wider, and wide is what the calendar is designed to prevent.
How agents fit
Agents do most of the typing on a sprint. They do not do most of the deciding. The split is deliberate. The tasks that go to agents are the ones with a crisp definition of done and a test that proves it: migrations, CRUD endpoints, UI from a token set, test coverage, documentation. The tasks that stay with humans are the ones where the spec is the hard part.
In practice the sprint owner writes task cards in the evening, agents run overnight, and the morning starts with a review queue. A good night produces eight to twelve pull requests. A bad night produces two and a note explaining where the spec was ambiguous. Both are useful. The bad night usually finds a problem in the spec that would have cost a day later.
The rules we hold
- One outcome per sprint. If a sprint has two goals, it has zero.
- Production on day two. A deploy pipeline that works is worth more than a feature that does not.
- Cut scope, never the date. The end date is the only fixed input.
- Every change ships behind a flag. Rollback is a config change, not a redeploy.
- Agents propose, humans merge. Every pull request gets a human read before it lands.
- No new dependencies after day five without a written reason in the pull request.
What a sprint spec looks like
The spec is one file in the repository. It is short enough to read in two minutes and specific enough that an agent can be handed a slice of it. The done sentence at the top is the one we test against on day ten.
What we ship on day ten
Working software in production, a short handoff note, and a proposal for the next sprint or a recommendation to stop. The handoff note lists what shipped, what was cut and why, what is behind a flag, and what we would do first with one more day.
We also leave the tooling behind: the deploy pipeline, the flag system, the eval suite for any agent we shipped, the task cards. You own all of it. Nothing in the build depends on us staying, and the next sprint, if there is one, starts from the same repository with the same rules.
When a sprint fails
Sometimes day five shows the outcome is not reachable in ten days. We say so on day five, not day ten. The options are the same every time: cut to what is reachable, or stop and refund the unused days. Most partners cut. A few stop. Both are fine outcomes. The bad outcome is a day-ten surprise, and the calendar exists to make that one impossible.
The one-sentence test
If the sprint owner cannot say what done means in one sentence at kickoff, the sprint does not start. Every late sprint we have run failed this test on day one and we ran it anyway.
This is how we run Build sprints today. It changes as our tooling changes, and the current version is always the one in the repository. If you run sprints differently and it works, we want to hear about it. DM @chancerobertson on X.