Sprint Planning Assessment

Every question on the Sprint Planning Assessment maps to a habit that separates teams who finish what they commit to from teams who carry work over every sprint and cannot explain why. Below is a breakdown of each scored question: what it measures, why it matters, and concrete steps to improve if your team scored low.

Score Interpretation

How to read your total maturity score (0 to 100).

1 to 20: Struggling. Planning is not producing a plan. The team leaves without a goal, without ready work, and without a shared view of capacity, so the sprint is decided during the sprint.

21 to 40: Developing. The meeting happens on schedule but the inputs are weak. Stories arrive oversized and unclear, commitment is based on optimism, and dependencies surface after the sprint has already started.

41 to 60: Norming. The basics hold. The right people attend, the backlog is mostly ready, and a goal usually gets set. The next gains come from sizing commitment against real data and reserving capacity for the work that always shows up.

61 to 80: Performing. Planning produces a plan the team believes. Stories are split, the Definition of Done is applied, dependencies are named, and the team pulls its own work. Tune confidence checks and retrospective follow through.

81 to 100: Thriving. Planning is a genuine advantage. The team commits to a goal it can defend, sized against its own history, with technical debt and dependencies accounted for before day one.

Team Size

What is the number of team members including the Scrum Master, Product Owner, and Tech Lead?

Why it matters: Sprint Planning is a negotiation about capacity and scope, and both get harder to hold in one conversation as the group grows. Six to nine people is the range where everyone can speak to the work and the team can still reach genuine agreement inside a timebox. Below six, you usually lack a skill needed to finish a story end to end, so commitments depend on someone outside the team. Above twelve, most attendees disengage and a small subset plans on everyone else’s behalf.

To improve your score: If you are at thirteen or more, look hard at whether you are running two teams from one backlog. Split them, give each its own goal and its own planning session, and let each build its own velocity history. If you are under six, confirm you have every skill needed to reach done without a handoff, and either add that skill or plan explicitly around the dependency instead of pretending it is not there.

Attendance

How many people were in attendance?

Why it matters: Team size sets the ceiling, attendance tells you what actually happened. People who miss planning did not agree to the commitment, did not hear the goal, and did not raise the risk they could see. They then get handed work they never sized. Very high attendance is its own signal, usually meaning managers and adjacent teams are observing, which makes the team perform rather than plan honestly.

To improve your score: Treat planning as the one session with no optional attendees for the delivery team, and reschedule rather than plan without a core skill in the room. Track attendance for four sprints and look for the pattern instead of reacting to one bad week. If observers are inflating the count, ask them to attend the demo instead, where their input is actually useful.

Roles Present

Who was present?

Why it matters: Planning needs three perspectives simultaneously: someone who owns the why and can decide scope, someone who can say how hard the work really is, and someone who keeps the session on time and on purpose. Without the Product Owner, the team guesses at intent and commits to its own interpretation. Without the Tech Lead and engineers, estimates are wishful. Without the Scrum Master, one story consumes the hour.

To improve your score: Publish a short required versus optional list and hold to it. Give each role a job in the session: the Product Owner states the goal and answers scope questions, the Tech Lead flags technical risk and dependencies, the Scrum Master runs the timebox and captures decisions. Name a backup for each role so a single absence does not force you to plan without a perspective.

Facilitation

Who facilitated?

Why it matters: Whoever facilitates shapes what the session optimizes for. A Scrum Master who facilitates keeps the trade off between scope and capacity in the open and makes sure the quietest engineer gets to voice a concern. When the Product Owner facilitates, planning tends to drift toward filling the sprint. When the Tech Lead facilitates, it tends to drift toward technical design. When nobody owns it, the session becomes a walk through the backlog with no decision at the end.

To improve your score: Give the Scrum Master explicit ownership of facilitation so the Product Owner can focus on value and the Tech Lead on feasibility. Use a repeatable flow: confirm capacity, propose a goal, pull and size stories against that goal, surface dependencies, then confirm commitment. Name a backup facilitator in advance and have them run one session per quarter so the skill is not held by one person.

Cameras On

Were cameras on?

Why it matters: Commitment depends on doubt surfacing before the sprint starts, not after. Cameras are how a facilitator catches the hesitation when someone accepts a story they do not understand, or the look that says the estimate is optimistic. Audio only planning hides that, and silence gets recorded as agreement. Camera off sessions also make multitasking easy, and a distracted team will accept whatever scope is proposed.

To improve your score: Set a team norm for cameras on during planning and explain the reason rather than just stating the rule. Keep the session tight enough that being on camera is reasonable. If people consistently opt out, find out what is driving it, whether that is meeting load, home setup, or discomfort, and solve that instead of repeating the request. In person sessions satisfy this automatically.

Session Length

How long did the meeting last?

Why it matters: Thirty to sixty minutes is the range where a well prepared team can set a goal, pull work, and check capacity with real attention. A session much shorter than that usually means the team accepted a pre built sprint without questioning it. A session past an hour usually means the backlog was not ready and planning turned into refinement, or the team is designing solutions instead of committing to outcomes.

To improve your score: Timebox planning and protect the inputs that make the timebox realistic, which means a refined backlog and a known capacity number before the meeting starts. When one story consumes the timebox, treat that as data: it is too large or too vague, so split it or leave it out of the sprint. Move deep technical design into a follow up session with only the people who need to be there.

Backlog Visibility

Was the backlog visible for user stories to be added to the upcoming sprint?

Why it matters: If the backlog is not on the screen, the team is planning from memory and from whatever one person narrates. Nothing gets updated in the tool during the session, so decisions live in someone’s head and the sprint board does not match what the team agreed. A visible backlog also keeps priority honest, because everyone can see what is being left out and can challenge it in the moment.

To improve your score: Share the backlog at the start of every session and move items into the sprint live as the team commits to them. Assign a scribe so estimates, notes, and open questions land on the story before the group moves on. If your tool is too slow to work in live, fix that friction first, because it quietly pushes the team back toward planning from memory.

Backlog Readiness

Was the backlog ready?

Why it matters: Readiness is the single biggest predictor of whether planning produces a real commitment. When stories arrive without clear outcomes, acceptance criteria, or sizing, planning becomes refinement under time pressure and the team commits to work it does not understand yet. Those stories are the ones that stall mid sprint and reappear as carryover.

To improve your score: Hold a separate weekly refinement session so readiness is built before planning rather than during it. Agree on a short Definition of Ready, usually five to seven checks, and let the team decline anything that does not meet it. Give the Product Owner a standing expectation that the top of the backlog is prepared two days before planning, which leaves time to close gaps rather than discovering them live.

Story Splitting

Are large or unclear stories split into smaller, well-defined pieces before the team commits to them during planning?

Why it matters: Oversized stories are how sprints fail quietly. A story that spans most of the sprint hides risk, blocks parallel work, and produces a board where everything is in progress and nothing is done. Teams that do not split end up measuring partial credit, which makes velocity meaningless and makes forecasting impossible.

To improve your score: Adopt a shared splitting vocabulary so the team has moves to reach for: split by workflow step, by business rule, by happy path versus error handling, by data variation, or by interface versus logic. Set a rule of thumb that a story should be finishable in a few days by one or two people, and treat anything larger as a splitting candidate before it enters the sprint. Practice on one oversized story per session until it becomes reflex.

Sprint Goals

Did the team identify one or more Sprint Goals?

Why it matters: A sprint without a goal is a list of tickets, and a list gives the team no basis for deciding what to do when something goes wrong mid sprint. The goal is what lets a team drop a low value story to protect the outcome, and what lets a stakeholder understand the sprint in one sentence. Teams without goals tend to measure success by how many points closed, which is not the same as delivering something valuable.

To improve your score: Write one goal per sprint as an outcome a customer or stakeholder would recognize, not as a summary of the tickets. Propose the goal before pulling stories so scope follows purpose rather than the reverse. Post it on the board, reference it at the daily standup, and open the demo with it so the team sees the goal used rather than filed away.

Ready Work Depth

How many sprints are refined and ready in the backlog?

Why it matters: Depth of ready work is what makes planning fast and low stress. Less than a sprint of ready work means every planning session starts with a scramble and the team commits to whatever is closest to ready rather than what is most valuable. Very deep refinement has its own cost, because detailed stories that sit for months get rewritten before anyone builds them, and that rework is invisible waste.

To improve your score: Aim for roughly two sprints of ready work and check the number at the end of every refinement session so it becomes something the team manages on purpose. If you are running thin, spend the next two refinement sessions building breadth instead of perfecting the top story. If you are over refined, stop detailing beyond the second sprint and let items further out stay coarse.

Definition of Done Check

Does the team check candidate stories against a shared Definition of Done before committing to them in planning?

Why it matters: A commitment only means something if everyone agrees what done means. When the Definition of Done is not applied at planning, teams size the coding and forget the testing, documentation, review, and deployment that the same story requires. That is why work looks finished on day eight and is still open on day ten. It is also how quality debt accumulates without anyone deciding to take it on.

To improve your score: Put the Definition of Done on screen during planning and read it against the stories the team is about to pull, asking specifically what each item requires for testing, review, and release. Keep it short enough to be usable, usually six to ten checks. When the team repeatedly cannot meet an item, that is a signal to fix the underlying constraint rather than to quietly drop the check.

Product Owner Engagement

Is the Product Owner present and actively answering questions throughout sprint planning?

Why it matters: Presence is not the same as engagement. A Product Owner who attends but does not answer questions leaves the team to guess at scope, and those guesses become rework. Planning generates the highest density of scope questions in the whole sprint, and every question that goes unanswered in the room becomes a blocker later, usually on the day the work was supposed to finish.

To improve your score: Give the Product Owner an active role in the session rather than an opening statement, which means staying for the full timebox and making scope calls live. Track how many questions get parked with no answer and review that count with them. If they are stretched across multiple teams, agree on a fixed planning slot and protect it, and give the team a named delegate with real decision authority for the rare miss.

Story Assignment

How were user stories or tasks assigned to team members for completion?

Why it matters: Who chooses the work determines who owns it. Self assignment produces commitment, spreads knowledge, and lets the team reshuffle when priorities shift. Assignment by a manager, Scrum Master, or Product Owner produces compliance, hides capacity problems, and quietly creates a set of individual queues instead of a team plan. Leaving work unassigned is the other failure, because a story nobody has picked up is a story nobody is watching.

To improve your score: Let the team pull work in priority order during planning rather than distributing it. Pair on the stories only one person can do, and treat every one of those as a cross training target so the concentration does not persist. If someone is assigning work, name the reason directly, because it is usually either low trust or unclear priority, and both are addressable.

Sprint Length

How long are the team’s sprints?

Why it matters: Sprint length sets your feedback interval. Two weeks is the common sweet spot because it is long enough to finish meaningful work and short enough that a bad plan costs you ten days, not a month. One week sprints raise the overhead of planning and demo relative to the work done and punish any story that cannot be split small. Three weeks or longer delays feedback so much that the plan is usually stale before it ends, and carryover becomes normal.

To improve your score: If you are running three weeks or more, move to two and use the change as a forcing function for smaller stories, since work that will not fit is a splitting problem rather than a length problem. Keep the length fixed for at least a quarter so velocity data stays comparable. If you are at one week and planning feels rushed, two weeks will usually buy back the time without slowing feedback much.

Velocity Based Commitment

Does the team size its sprint commitment against actual historical velocity rather than gut feel?

Why it matters: Commitment made on gut feel is systematically optimistic, because teams plan for the sprint where nothing goes wrong. Historical velocity is the correction. Without it, the team overcommits, carries work over, and then treats carryover as normal, which destroys the credibility of every forecast it gives. Velocity is not a productivity target, it is a capacity signal that keeps the plan honest.

To improve your score: Use the average of your last three to six sprints as the starting number and adjust it down for known absences, holidays, and support duty. Say the number out loud at the start of planning and stop pulling when you reach it. Count only work that met the Definition of Done, since counting partial credit inflates the number and hides the problem. If your team does not use points, count completed stories instead, which works fine once stories are consistently small.

Dependency Identification

Are cross-team or external dependencies identified and discussed during sprint planning, before the sprint begins?

Why it matters: Dependencies discovered mid sprint are one of the most reliable ways a sprint goal slips. Planning is the last cheap moment to find them, because there is still time to resequence the work, start the conversation with the other team, or split the story so the part you control can move on schedule. Once the sprint is running, your plan is hostage to somebody else’s queue.

To improve your score: Make dependency a standing question on every story pulled into the sprint: does this need another team, a vendor, an approval, data, or an environment we do not control? Record the dependency with a named contact and the date you need it by. For anything unresolved at planning, either sequence it later or split out the independent part, and never commit to a story whose external input has not been confirmed.

Technical Debt Capacity

Does the team reserve a portion of its sprint capacity for technical debt and defect work rather than planning at full feature capacity?

Why it matters: Defects and maintenance arrive whether or not you planned for them. A team that fills the sprint entirely with features either drops the goal to handle a production issue or lets debt compound until velocity falls for reasons nobody can point to. Reserving capacity makes that cost visible and turns it into a decision rather than a surprise.

To improve your score: Set an explicit reserve, commonly ten to twenty percent of capacity, and agree with the Product Owner what it covers. Look at what unplanned work actually consumed over the last few sprints and use that as your starting number rather than a guess. Keep a short prioritized list of debt items so the reserve gets spent on the highest leverage fix instead of whatever is nearest, and report on it at the demo so the investment stays visible to stakeholders.

Retrospective Follow Through

Are action items from the previous Sprint Retrospective referenced or addressed during sprint planning?

Why it matters: Retrospective actions that never reach planning do not happen. The team names the same problem every two weeks, watches nothing change, and gradually stops raising real issues, which is how a retrospective becomes theater. Connecting the two events is what turns improvement from an intention into work with capacity behind it.

To improve your score: Pick one or two improvement actions per sprint, no more, and give each a named owner and a visible place on the sprint board rather than a line in meeting notes. Open planning by reviewing the previous actions and stating plainly whether each was done. If an item survives two sprints untouched, either fund it properly with capacity or drop it and say why, because carrying it silently is worse than either.

Confidence Check

Does the team do an explicit confidence check or gut-check vote on its sprint commitment before planning closes?

Why it matters: Without an explicit check, silence gets recorded as agreement and the people with doubts carry them privately into the sprint. A confidence vote takes two minutes and surfaces the disagreement while it is still free to act on. It also gives the Scrum Master a concrete signal to work with, because a plan the team rates as low confidence is a plan that needs scope removed, not encouragement.

To improve your score: Close every planning session with a simple vote, such as a show of five fingers or a thumbs signal, on whether the team believes it can meet the goal. Ask anyone below the midpoint what would raise their confidence, and act on the answer before the session ends by cutting scope, splitting a story, or resolving a dependency. Record the number and compare it against what actually happened, which teaches the team to read its own signal accurately.

Sprint Demo Discussion

Was the sprint demo discussed?

Why it matters: Talking about the demo during planning forces the team to describe what a stakeholder will actually see at the end of the sprint. That question exposes commitments that are technically real but have no visible outcome, and it catches the case where every story is backend work and there is nothing to show. Teams that skip it often reach demo day and assemble a story afterward.

To improve your score: Spend the last five minutes of planning naming what will be demonstrated, who will present each piece, and which stakeholders should be there. If the answer is that nothing will be visible, revisit the plan and pull at least one item that produces a demonstrable outcome. Capture that list on the sprint board so preparing for the demo is part of the work rather than a scramble the morning of.