Running Sprint Planning and Agile Sprint Execution

Run sprint planning that sets one sprint goal, fits real capacity, and keeps the goal intact through execution to a usable increment.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Sprint planning is the event that starts each agile sprint. The team decides why the sprint matters, what it can finish, and how it will do the work. Execution is everything that follows until the sprint review: daily coordination, handling surprises, and keeping the goal intact. This skill treats the two as one loop, because most planning problems only show up during execution.

The Scrum Guide frames Sprint Planning around three topics: "Why is this Sprint valuable?", "What can be Done this Sprint?" and "How will the chosen work get done?" It timeboxes the event "to a maximum of eight hours for a one-month Sprint", with shorter sprints usually needing less. Sprints are "fixed length events of one month or less", and the output of planning is a Sprint Goal plus a Sprint Backlog, which the guide describes as "a highly visible, real-time picture of the work" the Developers plan to accomplish.

The Sprint Goal is easy to treat as a formality, yet the rest of the plan depends on it. A goal gives the team a way to decide what to do when something unexpected happens. The Scrum Guide says that during the sprint "No changes are made that would endanger the Sprint Goal", while scope "may be clarified and renegotiated with the Product Owner as more is learned." Without a goal, every new request competes with every planned item and the sprint turns into a queue.

Capacity is the other half. The Agile Alliance defines velocity as the total of estimates for stories completed in an iteration, and warns that it is "a 'measurement', made after the fact" and "not itself a budget or a forecast" (Agile Alliance, Velocity). Good planning uses recent history as a guide, adjusts for known absences and interruptions, and leaves room for the unexpected.

The agile principles ask for a pace the team "should be able to maintain" indefinitely. A team that plans honestly and finishes what it plans builds trust with stakeholders faster than one that overcommits and carries work over.

How It Works

The loop has four parts: prepare, plan, execute, and close.

Prepare. Planning goes well when the top of the backlog is already understood. The Scrum Guide calls items that can be Done within one Sprint "ready for selection." That readiness comes from refinement in the previous sprint, covered in the backlog skill. If planning turns into a long clarification session, the fix belongs in refinement.

Plan. The Product Owner proposes why the sprint is valuable and the team shapes that into a goal. The Developers then select items that serve the goal and fit their capacity, and break the first items into tasks. The Developers own the "how" and the size of the commitment. The Product Owner owns the order of the backlog.

Execute. During the sprint the team inspects progress toward the goal every day at the Daily Scrum, "a 15-minute event for the Developers" (Scrum Guide). The guide also says the Daily Scrum "is not the only time Developers are allowed to adjust their plan." A visible board and a simple progress chart show whether the goal is at risk early enough to act. When new work arrives, the team and Product Owner ask one question: does it serve or endanger the goal?

Close. The sprint ends with a review of the increment with stakeholders and a retrospective. Velocity and carry-over from this sprint feed the next planning session. The guide describes the review as "a working session" and says the team "should avoid limiting it to a presentation."

Estimation supports planning without being the goal of it. Many teams use relative sizing such as story points and techniques like Planning Poker, where estimators choose privately and reveal at the same time so that nobody anchors on the first number (Mountain Goat Software, Planning Poker). Others count items once stories are consistently small. Either works if the team uses it consistently.

Step-by-Step Guide

Step 1: Check backlog readiness before the meeting

A day or two before planning, the Product Owner and a developer review the top of the backlog. Each item near the top should be small enough to finish within the sprint, with acceptance criteria the team understands. Flag anything that is not ready and either refine it or move it down. Planning with unready items is a frequent cause of long, frustrating sessions.

Step 2: Agree why the sprint is valuable and set the goal

Open planning with the Product Owner's view of what would make this sprint valuable. Discuss it with the team and turn it into a one-sentence Sprint Goal that describes an outcome, such as a customer being able to complete a new task. Check that every team member can state the goal in their own words. If the goal is a list of unrelated items, the sprint has no focus yet.

Step 3: Work out capacity

Start from what the team finished in recent sprints, then adjust for holidays, on-call duty, planned training and other known interruptions. Treat velocity as the Agile Alliance describes it, a measurement after the fact rather than a target. If the team is new, plan conservatively and learn from the first few sprints. Write the capacity down so the team can compare it with the result later.

Step 4: Select the items that serve the goal

Pull items from the top of the backlog that contribute to the goal, stopping when the selection fills capacity with some slack left for surprises. If an item near the top does not serve the goal, ask the Product Owner whether it belongs in this sprint. Items selected only because they are next in the list dilute the goal.

Step 5: Plan the first days of work

For the items selected, break the first few into tasks of a day or less, and agree who starts on what. The Scrum Guide leaves the "how" to the Developers, and plans for later items can stay rough until they start. Look for dependencies and risky items and schedule them early, when there is still time to react.

Step 6: Make the plan visible

Put the goal, the selected items and their tasks on a board the whole team sees every day. Show what is in progress and what is blocked. A visible plan lets the daily standup focus on the goal and lets stakeholders see progress without asking for status reports.

Step 7: Protect the goal during execution

When new work arrives mid-sprint, the Product Owner and team decide together whether it serves the goal, can wait, or is urgent enough to change the plan. If something must come in, something of similar size usually goes out. If the goal itself becomes obsolete, the Product Owner can cancel the sprint and the team replans. Record every mid-sprint change so the retrospective can look at the pattern.

Step 8: Close the sprint and feed the next one

Hold the sprint review with working software and real stakeholders, and update the backlog based on their feedback. In the retrospective, compare the plan with the result and adjust how the team plans. Record what was finished for the next capacity estimate, and return unfinished items to the backlog for re-ordering.

Best Practices

• Write the goal as an outcome a user or stakeholder would notice. "Customers can reset their own password" guides decisions. "Finish tickets in the sprint" does not.
• Keep planning within its timebox. The Scrum Guide sets eight hours as the maximum for a one-month sprint, and short, focused sessions depend on refinement done beforehand.
• Leave slack. Plans that fill every hour guarantee carry-over, because something unexpected happens in almost every sprint.
• Keep velocity inside the team. The Agile Alliance notes there is no meaningful comparison between teams that estimate differently.
• Start the riskiest items first. Discovering on the last day that an integration does not work leaves no time to recover.
• Finish before starting. Swarming on fewer items at once gets items to done and exposes blockers sooner than spreading the team across many.

Common Mistakes

• Planning without a goal: A sprint that is only a list of tickets gives the team no basis for handling surprises. Agree the goal before selecting items.
• Treating velocity as a target: Pressure to raise velocity leads to inflated estimates and lower quality. Use it only to plan.
• Overcommitting every sprint: Chronic carry-over tells stakeholders the plan is unreliable. Plan to recent actuals and add work mid-sprint if the team runs ahead.
• Letting anyone add work mid-sprint: Changes that bypass the Product Owner and the goal break focus. Route all new requests through the Product Owner.
• Skipping the review because nothing is finished: This hides the problem. Hold the review, show what exists, and discuss why the goal was missed.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Agile

Related Skills

• Product Backlog Management and Refinement
• Facilitating the Daily Standup Meeting
• Running Sprint Retrospectives for Continuous Improvement
• Choosing Between Scrum, Kanban, and Scrumban

Sources

• Ken Schwaber and Jeff Sutherland: The Scrum Guide
• Agile Alliance: Velocity
• Mike Cohn: Planning Poker
• Principles behind the Agile Manifesto

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.