CHAPTER 4: Preparing for Sprint Planning

My notes out of the book “A Practical Guide to Distributed Scrum”

Sprint planning =

• Review of highest priority items with PO + decision on how much work could be done according to previous sprints and velocity
• Task break down to decide how the work will get done
• Commit to the sprint plan

Risk at the sprint planning is that PO cannot answer team’s questions without contacting stakeholders who are not available in the meeting. This is often the sign that the team is not ready to do the Sprint Planning meeting.

There is no official pre-planning meeting in SCRUM but the team needs to have ready for the sprint planning the following points

• A prioritized Poduct BackLog
• User stories the team can complete within a sprint
• Clear acceptance conditions for each user story

Preplanning meeting can make the sprint planning meeting shorter

Preplanning

• Discuss and clarify acceptance conditions for high-priority user stories.
• Provide a relative estimate to help the PO identify their priorities
• Break down high priority user stories so that they can fit within a sprint
• Consider story dependencies owned by different teams

Clarification of user stories

The participants have to confirm that the stories have the same meaning to everyone and that they understand what the deliverables for a user stories are.

Hint: A good mean to make sure participants have the same understanding is to make them rephrase it with their own words.

• The product owner answers questions or take note of them if he cannot answer to get ready for the Sprint Planning
• The team can identify what needs to be investigated technically speaking to be able to commit at sprint planning
• The participant confirm if the estimates seem accurate

Breaking down User Stories

Looking at the stories only at the sprint planning – particularly at the beginning of projects – may lead to long time of disaggregating user stories instead of planning for the sprint. The can lead to create user stories sprint after sprint and the team may never understand the quantity of work they need to do for the release.

KEY POINT: The large user stories must be breakdown the soonest possible in the release to make the team understand how much work they need to do. Teams should not create user stories for the release from sprint to sprint

Estimating user stories

When new stories are added to the backlog, the team can estimate them at pre planning meeting

Dealing with dependencies

3 types of dependencies

• Simple dependency : A user story needs another user story done within the same team
  • Solution : reorder priorities to do first standalone user stories
• External dependency : A user story needs another user story done from and other team
  • Negotiate integration and delivery dates and reorder priorities
  • The team should not commit the dependent user stories before integration of the other
• Intertwined dependency: Two user stories need each other to get done.
  • Rework user stories breakdown to get simple dependencies

Cleanup of Product Backlog

The Product Backlog is not a Parking lot for every possible feature that could potentially be in the product.

The Product Backlog must be cleanup up so that it reflects what the team is likely to address. Stories with very low priority can be removed from the PB.

Approaches for the sprint preplanning meeting

• 1 meeting at each sprint or 1 meeting every week or as needed
• The regular meeting is best to get into a rhythm and limit interruptions
• Time box the meetings to remain focused. 1 hour is good.
• Sprint preparation can be 5 to 10% of team time

A ) The Full Team Approach

Regular meeting that involves the entire team.

PROS :

• Provide a sense of team ownership
• All team members can ask questions or voice concerns
• The team can use meeting to size the stories
• It allows the PO to get info from stakeholders before the Sprint Planning meeting

CONS :

• It is harder to keep focus of the meeting with many distributed participants.
• It may be difficult to schedule a time that works well for all Scrum Team members

B ) The Preplanning Team Approach

Weekly preplanning meeting with PO and the smallest subset of team representatives able to select and describe stories

PROS :

• A smaller group of participant is more effective for teleconferences
• It allows the PO to get info from stakeholders before the Sprint Planning meeting
• It reduce the disruptions on the work of team members for the current Sprint

CONS :

• There is a potential loss of communication or information by not having the full team present.
• Neglecting to go back to the whole team for their contributions can result in a loss if team ownership.
• This approach can easily slip from Scrum to a command and control center

C ) The Balanced Team Approach

Compromise between Full-Team and Preplanning Team approach.

Weekly meeting with a core group of participant and the entire team as optional participant. The entire team is present only for the last meeting before the sprint planning

PROS :

• A smaller group of participant is more effective for teleconferences
• It allows the PO to get info from stakeholders before the Sprint Planning meeting
• It provides a sense of team ownership
• All team members can ask questions or voice concerns
• It allows the optional team members to manage the disruptions on their work for the current sprint

CONS :

• There may be a loss of communication or information because the full team is not always present