Note: Sprint planning is something all users that are members of a sprint and have a section of the backlog delegated to them can do.
The purpose of sprint planning is for the team to create a plan of how to complete valuable work. Break down high prio user stories into tasks, understand if it fits with the teams current velocity. Facilitated by a SCRUM master or similar role, the whole team including the product owner participates in this timeboxed meeting.
For a successful sprint planning this is necessary:
- A refined product backlog with small user stories with clear acceptance criteria and priorities that is understood by the team.
- An empty sprint backlog with as little as possible pre-filled / old stuff.
- A chart showing the past velocity in previous sprints (assuming fixed sprints lengths).
Step 1: Can anything be improved from last time?
- Revisit retrospective notes and how last sprint went and make any improvements needed to for example the definition of done.
Step 2: The Product Owner Explains the Highest Ordered Product Backlog Items
- Open the Product Backlog. If multiple product owners, right-click on the part the product owner owns and select View Selected Only
- Change to Priority view (top left corner where it says Hierarchy)
- Show > Show user story in list to see the user story. Walk through the acceptance criteria of the top items and let the team members ask questions if needed.
- If bugs are managed in the QA view, make sure to walk through the bugs that have top priority to be fixed as well.
Step 3: Decide on a theme and create the sprint
- Select the previous sprint just finished and create a new sprint (by selecting the previous one the users will the same and it will be placed directly after in the timeline automatically).
- Double-click the sprint name in order to rename it. Give it a name that makes sense, preferably following a standard of some form (for example: YYMM - Team - Theme)
Step 4: Understand team velocity
- Go to Dashboards
- Create a chart with this setup:
- Sprint as the first dimension. Click on the dimension and filter on the past sprints for the team.
- Status completion as the second dimension. Filter this dimension to only show completed work.
- Measure: Add story points, estimated days, number of items or other relevant unit of measure for your velocity.
This chart can be reused each sprint planning and gives you a good indication of what the capacity of the team is. In the example above we can see that it is between 5-13 points.
- Not all teams are fixed, and you might want to make a change to who will be a part of the sprint. Do this under the User Allocation section in the sprint (right-click on a user name to change the allocated percentage):
Step 5: Commit work to sprint
- Move the highest priority work from the Product Backlog to the sprint (drag and drop or by selecting the sprint in the Committed to sprint column in the Product Backlog)
- Now the team breaks the story down into the tasks that is needed for the user story to be realized in the product. They also provide a work remaining in hours and assign it out to people (some teams choose to wait with assigning it out to people).
- Be careful so that you do not fill the bars with the capacity too much. It is common to never plan for more than 75 % of the available time of each person.
- Note: You probably also want to move in a couple of bugs (if any) from the QA section by selecting the sprint in the Committed to Sprint column there.
- Revisit the velocity chart (potentially change the options to not filter status and group stacked) to make sure that the current commitment is not too far off from what the team has achieved historically.
Now take a final look at your plan and make sure you have a common understanding of the team what must be done for this to work.