Sprint

When only the finish date was fixed and teams ran for months, there was no way to see what was taking shape in between. A six-month plan gets its first working screen in month four, and discovering the direction was wrong at that point throws away four months.

The plans didn't hold either. Over six months the market, the competing products, and what customers ask for all move, while the scope in the document is whatever got decided in month one. So requests arrive mid-flight, accepting them pushes the schedule, and cutting scope to recover the schedule produces something with no relationship to the original plan.

Cutting a long schedule into short segments of equal length came out of that. Leave something usable at the end of each segment and throwing away four months becomes throwing away two weeks. And the end of each segment creates a place to look at the direction again.

It's a segment with its start and end pinned to dates, and inside it what can change and what can't are separated. Five properties.

1. The length is fixed. Set it at two weeks and it stays two weeks. Change the sprint cadence, the chosen number of days in one sprint, every time and last cycle's results can't inform the next plan. Alternate three weeks and one week and the two results aren't comparable.
2. What's committed doesn't change mid-cycle. Once it starts, new work doesn't get inserted from outside. That principle guarantees the team two weeks of focus, and in exchange it makes urgent work wait for the next cycle. In organizations where something unwaitable appears every week, this is the first rule to break.
3. A one-sentence purpose gets attached. That's the sprint goal, what the cycle commits to achieving, written as one sentence. It differs from a list of twelve items: the list says what's being done, the goal says why these two weeks get spent this way.
4. Fixed occasions sit inside it. Sprint planning on day one to choose the work, daily scrum at the same time every day, sprint review on the last day to show what got built, and a retrospective that same day to examine how the team worked.
5. Each occasion has a time cap. The agreement not to exceed a set duration is called a timebox, and for a two-week cycle that's roughly two or three hours of planning, 15 minutes of daily scrum, and an hour each for review and retrospective. Meetings are usually kept under half a day out of ten working days.

The date arrives and it ends. Work left over does not extend the segment, and that's a property of the method rather than an oversight. Extend it once and the date loses its authority; without that, this cycle's result can't plan the next one. Three things get settled before moving on.

1. Confirm what remains in a usable state. What got added and actually works by the end of the cycle is the increment, and only work that passed the team's agreed completion criteria goes in. Something built but awaiting review doesn't.
2. Roll unfinished work into the next cycle and score it zero here. Award 7 points for an 8-point item that's 90 percent done and every cycle's number reads high, and the next plan built on that inflated figure slips again. The rolled item collects its full 8 in the cycle where it finishes.
3. Pick one or two things to change from the retrospective. That decision becomes an input to the next planning session, and skipping the occasion means the same problem recurs every cycle.

How much to commit next time comes from averaging the last three to five cycles. That average is called velocity, and figures sitting close together like 32, 30, 34 support a plan of about 32. Figures scattered like 12, 40, 25 average to 26 and that 26 guarantees nothing.

"That can't go into this sprint. Let's look at it in next cycle's planning."

Holding the principle that a started segment doesn't take new work.

"Three days left and we won't reach the goal. We need to decide now whether to cut scope."

Adjust the scope rather than extend the segment.

"Two or three items rolled over in each of the last three cycles. We're committing too much."

Repeated rollover signals that the volume of the plan is wrong.

Pagedeck runs two-week cycles. Mia opens planning on the morning of day one and writes the one-sentence goal on the board, where it stays for the full two weeks. When Theo gets an urgent request mid-cycle he passes it to Mia, who decides on the spot whether it waits for the next cycle or replaces something in this goal. Review and retrospective run back to back on the last afternoon, and one or two items from the retrospective open the next planning session.

The most common mistake is reading a sprint as a period of running flat out. The word means a short race, so the reading arrives naturally. But the method aims at the opposite. It looks for a pace the team can sustain cycle after cycle, which is why commitment volume gets set from the average of past results. Push one cycle up with overtime and that cycle's number inflates, and the next plan gets built on the inflated figure. Two or three cycles later the same overtime no longer covers it and the team looks like it fails every time.

Believing shorter cycles build faster is the other one. Halving two weeks to one looks like results twice as fast. But cycle length sets the interval for re-examining direction, not the speed of building. At one week, meetings that ran once per ten working days now run once per five, so the share of time they take doubles, and slicing work small enough to finish inside a week costs separate effort. Short cycles suit work whose direction shifts often; where requirements are settled, two or three weeks is usually better.