Sprint Planning meeting is conducted before the start of a sprint. The purpose of this meeting is to determine the sprint plan and set a sprint goal. This meeting is split into two sessions. In the first session, the product owner reviews the list of features and defines what needs to be built during the next sprint. The next session involves identification of tasks that need to be executed, in order to complete the build. The sprint planning meeting should yield the sprint objective and the sprint backlog.

Purpose of Sprint planning

The scrum team establishes and commits to an immediate goal and identifies requirements that support that goal by a set of user stories and supporting tasks that satisfy the team’s Definition of Done for each requirement.

Benefits of Sprint Planning

• Collaboration and Team Building
• Common Understanding of the Product
• Task Discovery
• Task Sign Up
• Task Prioritization
• Task Estimation
• Knowledge and Skill Set Improvement (two for one – you are training your staff!)
• Different Perspectives
• Promotes Just In Time (JIT) Planning

Invitees

• ScrumMaster (facilitator)
• Product Owner (sets the goal and priority)
• Development Team (plans the work to be done and determines how much it will take)
• Optional Invitees: Key stakeholders and/or other subject matter experts who can provide insight on user stories being considered

Preparation

• Identify the right people & schedule meeting with all logistics e.g. WebEX, Video conference, etc. – ScrumMaster
• Prepare and publish agenda – ScrumMaster
• Make sure the skills and capabilities of team members are known and are generally aligned with the needs of the backlog item candidates for the sprint – ScrumMaster
• Each feature or user story is small enough to be completed within a sprint and includes detailed requirements and acceptance criteria – Product Owner.
• Ensure backlog items are prioritized with the most important work items at the top and ready as per the team’s Definition of Ready – Product Owner.
• Update the team’s definition of done if needed and keep it ready for reference during the meeting – Development Team.

How to run a sprint planning meeting effectively?

Introduction

Define the sprint goal

The purpose of having a goal is to be able to select user stories that support the goal. It’s also really useful to assess at the end of the sprint whether you have been successful or not. Success is achieving the sprint goal, not just delivering all the stories you had planned to get done.

Decide how much to consider

Decide the number of stories for the current sprint. Make sure you take past data into consideration. Use Velocity as an input to determine how many story points should be accepted. The team should always be looking to stretch beyond what they’ve done in the past.

Are there any special circumstances this sprint that we need to take into consideration, like holidays, time off, training, company events, big demo, etc.?

Agreement on the bug fixes and support work

Agree on the percentage of the capacity that will be used for bug fixes and support work, if any. There are several ways to account for this:

Use a fixed capacity, such as 20%, for bug fixes and other support work.

Have the bugs linked to a user story and then size the story with bug fixes included, so there is no fixed reserved capacity.

Make sure the user story “Definition of Done” includes testing and bug fixes, as this helps deliver better quality software at the end of each sprint.

Decide which stories to do in this sprint

Look at your product backlog and discuss for each candidate story what it means, what you’re trying to achieve, and what success looks like. Choosing which stories to consider for your sprint is mainly determined by the sprint goal. Other considerations are:

1. What if we can do more than just the stories that support the goal?
2. What if there’s stuff we really want to do such as re-paying some technical debt?
3. What about high-risk items?
4. What are the stretch objectives we can consider but not commit?

Once you have decided which stories to aim for during the next sprint, move on to Task Planning.

Task Planning

Try to keep tasks to less than a full day’s work so that stuff moves through on a daily basis and there is a sense of progress and opportunity for collaboration during the daily standup. Also, try to split them in a way so that in theory different people could do different tasks.

Setup your board or visual workspace

This is the outcome of your sprint planning meeting: A fully populated board (JIRA or any other tool) or visual workspace with a list of user stories and associated tasks.

The outcome of Sprint Planning

• Scrum Team feels comfortable with the goal and has identified user stories that support the goal
• Product owner confirms that the sprint plan is aligned with vision, roadmap and release goal.
• Sprint Plan is completely captured on the team’s task board or agile tool.
• Burndown chart is set up.
• Each Dev Team member knows exactly what they will work on when they leave the meeting.

Mistakes to avoid in a sprint planning meeting

• Too much focus on getting the perfect task estimate
• Don’t start without a product backlog
• Don’t meet without the product owner present
• Don’t Force a Commitment
• Embrace Today’s Reality over Yesterday’s Estimate
• Don’t overcook, Meeting should not last longer than one hour for each week in the sprint.
• Don’t convert sprint planning to Backlog Refinement or Grooming meeting.

Checklist for Sprint Planning

When it comes to prioritization at the Sprint planning session itself, here are some possible questions that can help guide your decisions.

1. Which stories provide the most customer value (Prioritize by business value)? – Product Owner
2. Which items provide the most benefit to the business (Factor in the estimated effort to do the work)? – Product Owner
3. What is low-hanging fruit (Factor in the estimated effort to do the work)? – Product Owner & Dev Team
4. Which items are the riskiest (Mitigate risks by identifying and planning risky Items appropriately)? – Product Owner & Dev Team
5. Which items result in the highest cost if not done (Consider the cost of delaying a piece of work)? – Product Owner
6. What are the dependencies between items (Identify dependencies to work out a natural order of priorities)? – Product Owner & Dev Team
7. Which items contribute most to our Sprint goal (Determine what items contribute most to achieving the sprint goal)? – Product Owner
8. What is the next highest priority item to deliver this sprint? – Product Owner & Dev Team.
9. What else do we need to understand about this story? Is the deliverable and Definition of Done clear? Do the acceptance criteria adequately define the requirements of the story? – Product Owner & Dev Team.
10. Do we understand our implementation approach for this story? Do we need to have a quick discussion or schedule an offline meeting as part of this story work? – Dev Team.
11. What is our tactical approach to delivering this story? Can we list out the things we need to do? – Dev Team.
12. Are we considering all the work that is needed to fully complete & deliver the story? – Dev Team.
13. Is this user story and its tasks conducive to swarming so that one team member can take on one task at one time? – Dev Team
14. Check for conflicts – Can the set of stories in our sprint backlog be accomplished together in this sprint? – Dev Team.
15. Definition of Done – Will we be able to deliver a fully “Done” increment of our product at the end of the sprint? – Dev Team
16. Missing Backlog item – Is the team aware of any work that needs to be done that is not included in the sprint backlog, including maintenance and overhead items, spikes, release planning activities, or any other activity that needs to be accomplished this sprint? – Product Owner & Dev Team.
17. Risks: Are there any other risks or circumstances that we need to be aware of during this sprint? – Dev Team
18. Taskboard & burndown setup: Has our sprint plan been completely captured on our task board or in our agile tool? Are we ready to begin tracking our sprint, including producing sprint burndowns or other metrics we use? – Dev Team & ScrumMaster
19. Next steps: What will each team member start working on when they walk out of this meeting? Have each team member select one task to begin working on.
20. If issues came up during the meeting that requires follow up outside of the meeting, make sure they are documented and assigned for follow up as needed. Dev Team & ScrumMaster.

Scrum Blog: Click Here Scrum Guide: Click Here