Sprint Planning

The purpose of sprint planning is for the team to look at the upcoming sprint to define what can be delivered in the sprint and how that work will be achieved. This ceremony occurs on a bi-weekly basis (or before the new sprint starts) and allows the team to review any carry-over user stories, review what was discussed in backlog refinement, identify prioritized user stories, create sprint goal, and review team capacity & velocity.

Outcomes:

• SM will share with team the velocity - predictability of completed work from an average span of sprints to understand how much the team can take on and complete

• This will help determine how much the team can have in the sprint and how much confidence they have in completion

• Team will share any PTO or company-wide holidays so that the sprint is appropriately planned for

• Create or review the goal of the sprint

• What is the team trying to achieve? Any deadlines? Focus on the body of work?

• Ensure that stories are fully detailed, pointed, and assigned to a developer

• SM to facilitate "Confidence Level" / "Fist of Fives" - Ask each developer their confidence on completing his or her committed user stories

Best Practices:

• Try not to make sprint planning into another refinement session - the team should refrain from extending conversations on user stories previously talked about during the refinement ceremony; if additional time is needed - another refinement session will need to take place before sprint planning can occur

• If there are any carry over stories, have the developer complete as soon as possible so that other committed user stories will not be delayed or carry over

• The hope is to have the team velocity on a consistent predictable number

• If velocity is skewed, team should be able to explain why it occurred and identify a solution

Velocity v. Capacity

Velocity : This metric can determine the predictability of the team when it comes to completing committed work (the # of stories the team commits to and is considered done) each sprint. Velocity is also used to limit the amount of work taken on in further iterations as this is used for planning purposes and determines the delivery of value (i.e. a working increment of the product delivered to the customer).

Best Practice: To determine the velocity is by taking the past 3 sprints and averaging it out - look at Velocity Dashboard in ADO. The Scrum Master will then be able to coach the team to consider the number of user stories he or she takes on and has completed for a stronger predictability.

Capacity : This metric can determine the availability the team has in each sprint. When planning for future sprints with features ready to be developed, the product team can determine how much work can be planned for the sprint. Also consider any PTO or holidays within the team.

Best Practice: The Scrum Master to help calculate the amount of work that can be committed each sprint and provide to the Product Owner. (Under capacity, at capacity, over capacity)