Sprint Planning

1. Overview

Sprint planning is where we commit to the items we intend to work on during the next two weeks. We use a small iteration to maintain focus, allow for course correction early and often, and to keep the team involved as to changes being made.

2. Scope

This document covers how we perform sprint planning, it makes the assumption that the release planning has already been done and all issues in the release are scoped and final.

Intended audience: Project leads | Developers

3. Related Processes

• Release Planning
• Scrum Process
• Meeting Plan

4. Process/Main Body

The goal of sprint planning is that each team member knows what they are working on, and what the rest of the team is working on, and feels confident in their plan. To reach this goal, we work entirely in the GitHub Project.

Sprint planning occurs at the beginning of every-other CCCL team meeting. After a few iterations, it's a quick process.

• The lead shares their screen and moves to the Sprint View in the project
• In a round-robin style, the lead calls on people to discuss what Issues within the release they plan to work on during the next 2 weeks
  • Issues mentioned get their End Sprint value set to the current sprint
    • If the issue has not been previously worked on in another sprint, set Start Sprint to the current value as well
  • If there are issues that were selected to be in the last sprint that are not closed
    • If they intend on working on it, change the End Sprint value
    • If they do not, clear the Start Sprint value
• That's it

When you have the release properly scoped, and issues properly defined, sprint planning is very easy. It also reveals the challenges in release planning, and issue definition very well. Because of this, expect the first 3-5 sprint planning sessions to go a little awkwardly.

Start Sprint and End Sprint?

We have a pair of iteration fields in the projects, Start Sprint and End Sprint and they reflect the exact same time boxes. This is done because issues have no guarantee of being completed within a sprint. For the first two releases, expect it to be very common that issues spill between sprints.

Even in a world of perfect estimation, other things come up that pull the team's time away. Having the pair of sprint iterations allows us to capture a more true time of work, helping hone story point values, and improving estimation. It also lets us use the Roadmap views in GitHub projects, visualizing the timeline of a release.

5. References/Appendix

This section intentionally left blank.