7Cs of Sprint Planning

How do you do Sprint Planning? Are you struggling to keep the team interested in coming to Sprint Planning, every sprint?

Show them the VALUE! Use my 7Cs of sprint planning to keep your sprint planning on track and make it the most productive meeting for the team.

Let me explain each of these Cs in detail to help you make your Sprint Planning the most productive one.

Close

CLOSE refers to Closing your current sprint 🙂 You need to make conscious decisions on any of the ‘left over’ stories, the ones that the team did not complete during this sprint and then close the sprint in preparation for the next, upcoming sprint

Confirm

Confirm, as a Team, with the Product Owner (PO) that the Stories that are at the ‘top’ of the Product Backlog are still his/her highest priorities and that the team got them READY through previous refinement sessions.

Confirm that those stories are READY and meet the Definition of Ready (DoR) criteria. You can read more on DoR and DoD here https://www.nimeshsoni.com/art-getting-done-less/

Capacity

How many Stories can you load into the Sprint backlog? To answer this question, you will need to know the Velocity of the team as well as the capacity for this Sprint, as a Team.

When I say Capacity, I am not referring to how many hours. Instead, I am referring to the Day offs, Holidays, Planned Vacations, etc. Is any one taking any time off during this sprint? What about holidays and company-wide events that will take time away from this sprint and impact your capacity.

To help you answer these questions easily, I strongly recommend you set up a Team Calendar where each team member keeps his/her time-off requests. This team calendar becomes your go-to artifact to answer the Capacity questions.

Remember, the Capacity will also impact team’s Velocity.

Consensus

Bases on the discussion on Capacity, and using Velocity as a guide line, team should be pulling top priority items from Product Backlog into the Sprint Backlog. How many stories to load into the sprint will depend on the capacity and velocity.

As a team, you need to come to a consensus as to how many stories / story points is feasible in this sprint.

Commit

Once team has a consensus on the number of stories, story points and what stories to load, the team Commits to them. Team promises to do everything in their power to drive these stories to completion through this sprint.

This is where you can mark the completion of your Sprint Planning event. The team can go back to their work environment and actually start working on them.

The next two Cs are more for the Scrum Master than the entire team.

Communicate

Now that you have completed an awesome and highly productive Sprint Planning event, the Scrum Master should communicate to the stakeholders. Send out a communication as to what is the scope for this sprint, what stories were committed, and what feature/functionality the team is attempting to complete through this sprint.

This will keep the stakeholders in the loop, and they will know what to expect at the Sprint Review.

Remember one of the pillars of Scrum!? The Transparency!

Collect

I am not a big fan on Task writing. But, if team decided to capture Tasks under the stories, then we need to collect them quickly. I generally advise Scrum Master and team to set a deadline here. For example, by end of the day, enter any tasks that you may want to capture.