Sprint Planning

When work arrives through individual channels, a team does whatever each person received without knowing what comes first. On the receiving end there's no basis for choosing between three things three different people called urgent.

That was Pagedeck before cycles. Mia handed work over one item at a time by message, and Theo got urgent requests from three people in the same week. With nowhere to ask, he worked on whatever arrived last. Two weeks later, half of what Mia expected was finished, and other people's requests occupied the other half.

There was also no agreement about how much fits. Requests always exceed what a team can absorb, so without that agreement every cycle slips and the start of the next one gets spent explaining why. Sprint planning creates that agreement once, at the start of the cycle. After that, saying no has a reference rather than a feeling behind it.

Two things get decided in order: the goal for this cycle, and the items and volume that goal requires. Seven steps.

1. Tidy the candidate list beforehand. Start writing items during the meeting and two hours go to that, leaving no room for the conversation about volume. Refining the day before is what preparation means here. Anything still unclear at that point goes on a list of questions rather than into the cycle.
2. Write the goal as one sentence: what will be different when this cycle ends. A list of twelve items is not a goal. A one-sentence goal becomes the criterion when something has to come out mid-cycle. It also gives the team something to say when a new request arrives.
3. Pick the items. Take what the goal needs first, handled as user stories — one sentence each stating what someone wants from their own point of view.
4. Match the volume. Compare against what actually finished in recent cycles, and subtract time lost to vacation or support for another team first. If the requesting side rather than the building side sets the volume, this step becomes theater.
5. Split anything that won't finish in one cycle. What can't be split doesn't go in. A half-finished item delivers nothing at the end of the cycle. Splitting well is the skill that decides whether the rest of this works.
6. Confirm the completion criteria. What counts as done has to be written to the same standard across items, or the end of the cycle turns into an argument. Different standards per item mean several meanings of "done" inside one cycle.
7. Lock the list and agree not to take new requests mid-cycle. To allow exceptions, define what qualifies and what comes out when one arrives.

For a two-week cycle, under two hours is about right — short enough that a wrong goal costs two weeks and no more. Running past four usually means step 1 was skipped.

It's held on the morning the cycle starts, with everyone who builds in the room.

Attendees split three ways. The people building judge volume and slicing. Let anyone else make that judgment and the rest of the process is form without substance. The person who sets priority answers what comes first — at Pagedeck that's Mia, arriving with the goal sentence and the item order. Someone facilitating keeps time and pushes undecided items to later. Nobody in the room holds all three roles at once.

Stakeholders don't attend. The place to show results and collect opinions is the sprint review; add an audience to a planning meeting and the conversation about volume turns into a conversation about promises.

The timing is after the previous cycle's retrospective. The order matters: one improvement from the retrospective has to enter this plan as an item for that improvement to actually happen. Lock the plan first and hold the retrospective after, and whatever came out of it slides to the next cycle.

Once the cycle is running, daily scrum checks this plan every day. It's where plan and reality separating becomes visible, which is why a list that was too large shows up within the first two days. Teams running a one-week sprint hold this meeting to under an hour and cut the item count to match. Meeting length scales with cycle length rather than with the size of the backlog.

"What's the goal in one sentence? Listing twelve items isn't a goal."

Asking that the list and the goal be kept apart.

"The last three cycles finished six each and we just committed to ten. What comes out?"

Walking the volume back using the record.

"That's not going into this cycle. We'll look at it at the next planning."

Invoking the agreement against mid-cycle additions.

Pagedeck's first planning meeting took three hours. The candidate list wasn't ready, so half the meeting went into writing items. From the next round Mia refined the list the day before, and the meeting dropped to 90 minutes.

The goal sentence turned out to matter most. In arguments about what to drop, that sentence worked as the criterion. With the goal being to raise first-document creation among free users, improvements to the admin screen moved to later regardless of who called them urgent. Theo also stopped answering three people separately and started pointing at the sentence. The sentence was doing work the priority order alone had not done.

The most common reading is that this is the meeting where work gets assigned, because a list comes out of it. But what gets decided is the team's volume and order; who takes what is settled during the cycle. Nail down owners in the meeting and there's no room for someone else to pick up a blocked item, and a list split by owner stops being the team's goal and becomes six personal lists. The order the items sit in is what the meeting produces.

Reading the purpose as keeping to the plan is the other one, since a committed list makes finishing all of it look like success. But a plan is a forecast made from what was known at the time. When something new is learned mid-cycle, holding the goal while adjusting the list is the correct move. Forbid adjustment and the team defends the list rather than the goal, finishing items that stopped being useful days ago. What should stay fixed for two weeks is the goal, not the list under it.