Sprint planning agenda: the version that actually works.

Short answer: A sprint planning agenda has two parts: the 'what' (decide which stories are in this sprint) and the 'how' (each owner walks through how they'll execute their stories). For a two-week sprint, four hours is the right time-box — two hours per half. The moment it usually breaks is pointing under pressure: the team estimates to fit the sprint instead of to fit the work.

There are two halves to a sprint planning agenda: which and how. Decide which work will go in the sprint first. Then walk through how the team will deliver the work. Increments of four hours during a two-week sprint, roughly 50/50. All else is just variation.

Planning the Sprint is important because it signifies the contract between team members for next two weeks. When it runs long, the team kicks of the sprint exhausted. When it is scant the team begins with hidden disagreements on what is accepted as “done”. The below agenda retains its form despite both modes of failure.

It details the functioning 2 part structure, who needs to be in the room, the time boxing that actually holds, the moment in pointing where most planning meetings go sideways, and the most common sprint planning anti-patterns. SCRUM MASTER STUFF

The audience is scrum masters and anchors and PMs who’ve inherited a planning ceremony that takes too long and produces commitments none of the people actually believe.

Sprint planning, plainly

At the start of each sprint, a team meets in order to agree on what they are going to accept (that is, deliver to “Done”) within that sprint. Three outputs.

1. The sprint backlog — the ordered list of stories the team has committed to.
2. A working understanding of how each story will get done — not a full design doc; enough that the engineer picking up the story tomorrow won't have to ask the PM what was meant.

That’s the meeting. A one-line theme that summarizes the sprint is added by some teams. Certain teams overlook it. The agenda below assumes you've at least written down the goal (even if you don't make a ceremony of it).

The two-part format became established in the Scrum Guide and was rescued since it corresponds with the two genuine decisions: which tales, and how. When you mix the two scenarios, one gets a meeting where one’s estimating work one hasn’t agreed to do yet. Atlassian's sprint planning playbook lands on the same split for the same reason.

The two-question structure that frames the meeting

Every sprint planning discussion addresses two questions. The secret is to keep them apart.

Question 1: What are we committing to?

This constitutes the "what". The top of the prioritised backlog comes from the PM (product owner) The team deliberates about every story sufficiently to ascertain whether they can commit to it. Any story that’s not ready gets pushed back; either your PM elaborates on it on-the-fly, or they defer it to the next sprint.

The team agrees that an ordered list of stories is what they can finish (exit condition for q1).

Question 2: How will we execute?

This is the second half. For every accepted story, the owner reviews their approach with the team. At the implementation detail level, I will touch services and the risk is here and not sure about this part. When any user story breaks the assumptions made on the User Story, anything that turns out to be much bigger than the team expected or a bug that uses up time, then we are going to cut it from the sprint.

The exit condition for question 2 is that every story has an owner who can explain how they’ll implement it, and the team has agreed to this.

We must avoid conflating the two questions. When you start pointing stories while deciding which ones to take, you end up biasing the estimate to the sprint capacity rather than the work — the failure mode laid out in this breakdown of blocking-and-tackling iteration planning. Should you skip the “how” altogether, you start the sprint with the engineer who picked up the story discovering it is not what the PM thought.

Time-box: four hours for a two-week sprint

The industry standard is closing off an eight hour period for a four week sprint, scaled accordingly. A two week sprint is two hours for the ‘what’ and two hours for the ‘how’ for a total of four hours.

Why four hours and not six or two?

• Below three hours, the meeting under-shares context. People nod through stories they don't fully understand, and the disagreements surface mid-sprint instead.
• Above five hours, the meeting fatigues the team. By hour six everyone is signing off on whatever to end the meeting, and the team starts the sprint demoralised.
• Four hours is enough to discuss eight to fifteen stories — which is roughly what a team of five to seven ships in a two-week sprint. The bandwidth matches the throughput.

The time-box also forces the backlog to be groomed. If your team is consistently running out of time in planning because the backlog isn’t ready, that is sending you a signal. It indicates that the grooming should take place before you plan, not during — see finding the right amount of backlog refinement for how much is enough. Most teams that “have a long planning meeting” actually have a “we groom in planning” problem.

More often than not, if the meeting ends consistently half way into the time budget, that is also a signal. As in, it usually means the team is rubber-stamping a previously-decided backlog, and the PM is unilaterally making commitments. It is possible to recover either; however, both require the anchor to have it pointed out.

The agenda that actually works

A working agenda for a 2-week sprint, 4-hour time-box.

1. Sprint goal (5 minutes). The PM names the one-line theme of the sprint — a working approach to iteration goals covers what makes one useful. If the team has objections, surface them now, not in retro.
2. Capacity check (10 minutes). Who's out? Any holidays, on-call rotations, or planned context-switching? Adjust available person-days accordingly. Don't skip this — it's the only number that grounds the rest of the meeting.
3. Velocity reference (5 minutes). The PM shows the rolling-3 velocity average — a healthier approach to estimating velocity explains why a rolling window beats a single sprint number. Not as a target; as a sanity check. If the team accepts double their average, the anchor flags it.
4. Story-by-story commit (90 minutes). Walk through the top of the backlog one story at a time. The team accepts, defers, or asks for clarification. Exit when you've filled roughly the velocity-shaped budget.
5. Short break (10 minutes). Critical. The next half is more demanding; don't try to push through.
6. Story-by-story execution walk-through (80 minutes). Each story's owner explains their approach. Other engineers flag risks. Cut stories that turn out to be bigger than they looked.
7. Sprint kickoff confirmation (5 minutes). The PM and anchor confirm the final sprint backlog. Anyone with a remaining objection raises it now.

That is 205 minutes   just under four hours, which allows for a ‘five minute overrun’ on items 4 and 6. Should the team finish early, that’s recovered focus time, not a reason to extend the meeting.

Who must be in the room (and who shouldn't)

Inside the chamber.

• The team that will do the work. Engineers, QA, designers, anyone whose hands will touch the stories. No exceptions; remote attendance is fine, but every committer is present.
• The product owner or PM. They own the backlog ordering and they answer the "what does done look like" questions.
• The scrum master or anchor. They time-box the meeting and call out anti-patterns in real time.

Not involved in the work unless they're doing it.

• Engineering managers who aren't shipping. If a manager wants to know what the team is committing to, they can read the sprint backlog after the meeting. Presence in planning shifts the team's framing from "what we can ship" to "what we're being asked to ship".
• Stakeholders from outside the team. Sales, marketing, account managers, executives. They've already had their input in backlog prioritisation; planning is an internal commitment, not a sales review.
• Other teams' representatives. Cross-team dependencies should be resolved before planning, with a written agreement, not in the meeting.

It is not “smaller is better”. The sprint is being committed to or executed by everyone in the room. Crowd presence undermines resolve.

Pointing the sprint — the moment it breaks

In many sprint planning discussions, the pointing conversation works well. The template.

1. Team picks five stories that fit the velocity budget.
2. They point each story. The first three are easy.
3. The fourth story turns out to be larger than they thought.
4. Total points now exceed velocity capacity.
5. Someone says "I think we can fit it — the second story was lower than 5, it's more like a 3".
6. The team re-points the second story down to fit.
7. The sprint goes over.

One cannot see the machinery for what is inside the meeting: pointing under pressure becomes negotiation not estimation. The solution lies in the structure. The points are fixed independent and before the sprint, and the team accepts as many points as their velocity budget allows rather than re-estimating to fit. Picking a consistent scale also matters — linear vs Fibonacci pointing scales has the trade-offs. Tools such as the original Pivotal Tracker and LiteTracker that enforce stories-only velocity encourage this discipline by making points sticky. Martin Fowler's piece on estimation covers why the discipline holds: velocity is descriptive, not a budget to spend.

The cost of the ceremony tax is completely compensated: structured management of sprints helps teams ship (on average) 70% more value by their eighth sprint, but only if the points stay honest. When a team re-estimates items so they fit into the sprint, the velocity loses its predictive value in three iterations.

The most common sprint planning failure

Once you've worked with enough teams, you will see one anti-pattern dominating   the planning meeting degenerates to a forecasting meeting instead of a commitment meeting.

Symptoms

• The PM walks in with a sprint pre-committed (in their head or in a Slack thread the night before).
• The "what" half is theatre — the team rubber-stamps stories that were already chosen.
• Discussion happens but doesn't change the outcome.
• The "how" half gets skipped because the meeting ran long.
• The sprint ships fewer stories than planned, and the retro blames "unexpected complexity".

It’s not a new template for an agenda that’s the fix; it’s for the PM to stop entering the meeting with a fully baked plan. The sprint comes out committed and the backlog comes in prioritised. If they are one and the same, the meeting only serves to appease.

Another common mistake is skipping the meeting altogether due to agility.  Some teams don't do planning and just run on continuous flow and ship. A majority of teams that forgo planning are actually ditching the commitment stage, and this results in reduced throughput after a quarter as small misalignments add up.

When NOT to run sprint planning

The counterweight to sprint planning being “free” is that it’s not the right meeting in some situations.

• Pure kanban flow. If your team has no sprint boundary — work flows in continuously, gets done continuously — sprint planning is meaningless. Replace with weekly backlog review and per-story kickoffs; shorter iterations aren't always better covers when the sprint boundary itself stops paying for itself.
• Pre-product-market-fit startups. A team of three building the first version of something doesn't need a four-hour ceremony every two weeks. Verbal alignment plus a shared backlog is fine until the team grows.
• Pure operations / support teams. If the team's work is "fix whatever paged us", planning doesn't apply. Replace with weekly incident review.
• Cross-team coordination meetings dressed up as planning. Those are program-level meetings, not sprint planning. Run them separately; don't conflate the two.

If you are not a scrum practitioner, you usually have to run sprint planning. Execute the task as per the timetable mentioned above.     Maintain a boring agenda. Preserve the Time Box

Frequently asked

What is a sprint planning agenda?

A sprint planning meeting has a structured outline. There are two halves to this synchronisation, first deciding which stories are in the sprint (the ‘what’) and then walking through how each accepted story will be willed into being (the ‘how’). For a two week sprint, four hours total split half and half roughly.

How long should sprint planning be?

Scaling it down as per proportion for a four-week sprint might take up to eight hours. For a standard two-week sprint, a duration of four hours is appropriate. Five hours has a fatigued team, three hours leaks too much context.

Who attends sprint planning?

The product owner or PM, the scrum master or anchor, and the team doing the work (engineers, QA, designers). Engineering managers who aren’t shipping, external stakeholders, and representatives from other teams should not attend by default, as their feedback is incorporated into backlog prioritisation before planning, not in the meeting itself.

What's the difference between sprint planning and sprint grooming?

Grooming, also known as backlog refinement, is when the team clarifies, splits and rough-estimates stories ahead of planning. During the planning stage, the team commits to which of the refined stories would be in the next sprint. If you are doing grooming during planning, your backlog wasn’t ready and your meeting will over-run.

Should we point stories during sprint planning?

The points ideally shouldn’t   they should come from grooming before planning. When something is pointed under pressure of sprint coefficient, then its estimate is biased downwards to make fit the work If pointing must be done in planning, then do it before we commit and not after, and resist the urge to re-point when totals don’t match the velocity.

What's a sprint goal?

A sprint theme is a one-line summary of what the sprint is trying to achieve, “ship the password-reset feature”, “cut p95 latency on checkout”. It’s not mandatory but useful. It allows the team to make trade-off decisions mid-sprint without re-running planning. No need for a ceremony; one sentence will do.

What happens if the team can't fit the priority stories in the sprint?

We have three options when we realize a mid-sprint story isn’t shaping up. We can defer the lowest-priority committed story to the next sprint, we can split the over-large story into shippable pieces, or we can opt to under-deliver and then discuss that matter in retro. The incorrect solution is to scale back the estimates of the stories to make everything fit. That’s negotiation, not estimation.

How do you handle bug fixes in sprint planning?

You can implement two practices: include them in the sprint as their own stories (pointed) or keep aside a fixed percentage of capacity (20%) for unplanned bug fixes (unpointed). Consistently choose one; mixing velocities confuses values. Most teams find unpointed capacity-reserved work better   bugs are corrective work, not new value.

Still stuck

A four-hour long sprint planning meeting that cleanly splits between ‘what’ and ‘how’, and which produces a sprint backlog that the team believes is doing its job. Typically, the plot’s agenda is the easy part of planning. It’s who gets to attend and how long it runs that teams argue over.

LiteTracker is the tool for you if you want a tool that enforces stories-only velocity and surfaces a single ordered backlog so the ‘what’ half takes minutes instead of an hour. You can experience the free version for unlimited users. Please do not sign up if your team has fewer than three engineers or you aren’t doing iterations yet   a cognitive overhead will not pay back.

Keep your planning dull so that you are never surprised in the sprint.