Photo by CoWomen on Unsplash

What is Sprint Planning

In the Agile Scrum framework work is delivered in Sprints. Sprint are short duration delivery cycles (2 or 3 weeks). Sprint planning marks the beginning of a new sprint. It is a meeting that includes the Scrum Master, Product Owner, Delivery Team and sometimes other stakeholders. The purpose of Sprint Planning is to decide on a set of deliverables that will be completed in the sprint.

This diagram shows how the planning meeting moves a set of User Stories from the Product Backlog to the Sprint Backlog. The Product Backlog is the full scope of User Stories for the product, sorted by business value priority (highest value at the top). The Sprint Backlog is the scope of User Stories for the sprint. It is also known as the Sprint Forecast.

Sprint Planning answers the following:

What can be delivered in the increment resulting from the upcoming sprint? How will the work needed to deliver the increment be achieved?

(Scrum.org)

Sprint Goal

The Sprint Goal is specifically a business goal, or theme for the sprint. It may be a goal like preparing for a release, or fully completing an Epic. Sometimes the stories in the backlog are quite unrelated, and there may not be an obvious goal. There could also be a few goals. If there is a team process change identified in the previous sprint retrospective, enacting this change can be added to the sprint goals.

The Sprint Planning Meeting

Sprint planning can be divided into 2 sub-meetings or phases. The first phase includes the subject matter experts (SMEs) that are asking for the user stories. Include these people to help the team understand the requirements. User Stories are “placeholders for a conversation”. Bringing SMEs into sprint planning helps facilitate conversation.

Solution design is a large part of the planning meeting. The User Stories should only explain the business need and leave the how out. I will sometimes add solution assumptions to a User Story in order to estimate the Poker Points on a story,

Vetting solution ideas with SMEs is a good way to check for requirements gaps, or misunderstandings. Solutioning happens collaboratively with the stakeholders, Product Owner and delivery team. If the story size is not longer appropriate a quick re-estimate can be done. If the scope of the story expands greatly, try slicing off a smaller achievable story for the sprint backlog and defer additional work into the backlog.

Facilitating Sprint Planning

It is very important to understand that the team is pulling work from the product backlog into the sprint backlog. The Scrum Master has a responsibility to protect the sprint commitment, to ensure sprint safety. Which means protecting the scope of the sprint. Agile embraces change, but that change happens at sprint boundaries, not on in flight work. This responsibility extends to ensuring that the team does not commit more work than they can achieve. Because of this, I suggest that the Scrum Master facilitate sprint planning.

Some Tips:

• Ensure the backlog is well refined through backlog groomed
• Have an idea of what would be reasonable for the sprint backlog, set an agenda to allows the team to discuss these items
• Work top down on the product backlog, it is also ok to bring in a lower priority item if nothing else fits
• Encourage the team to volunteer for tasks instead of assigning tasks. Encourage team members to work on unfamiliar areas of the system
• Make sure the team truly believes the sprint has a high probability of success

Is the Sprint Full?

Sprint Velocity

Sprint Planning is a negotiation between the Product Owner and the team. If the sprint is full, I.e. the total poker points (see Planning Poker on the stories in the sprint backlog matches or exceeds the sprint velocity, adding another user story to the sprint backlog means something needs to be removed. The velocity is a metric that works well to evaluate the reasonableness of the workload.

Team Capacity

You may not have a sprint velocity if your project is just starting for example. Team capacity hours versus task hours is a good way to check if a sprint backlog is achievable. It works like this, for each team member work out their availability on the sprint, days off, allocation etc and add this up. Don’t worry too much about roles, just get a total team capacity in hours. As stories are added to the sprint backlog, task out the work and estimate the hours needed to complete the tasks. Accumulate the total task hours and ensure you don’t exceed the team capacity.

Expert Opinion

Do a gut check with the team. Does the workload seem reasonable? Have the team volunteer for tasks and once everything is assigned, do another gut check. As team members volunteer and pick up tasks, have them keep a running total that can be checked against their total availability for the sprint.

Summary

Sprint Planning is the Agile Scrum ceremony that starts a sprint. The Delivery Team, Product Owner and Scrum Master attend this meeting. SMEs and stakeholders can be invited for a portion of the meeting discussion focused on understanding the User Story requirements. The team pulls stories from the Product Backlog into the Sprint Backlog. Once the Sprint Backlog is full it becomes the sprint forecast. The Sprint Backlog is the scope of the sprint. The team focuses on delivering the Sprint Backlog in the sprint and the Scrum Master protects this scope.

Sprint Planning defines what is forecasted for delivery in the sprint and how it will be delivered, including solution design decisions and the tasks to implement the solution.

Sources Cited

What is Sprint Planning?. Scrum.org