Iteration (Sprint) Planning

What is it?

• An event where a development team collaborates with the Product Owner to align on the goal and outcome the team are going to focus on for their next iteration of development.
• Team members use this opportunity to further their shared understanding of the Product Owner’s (and stakeholders they represent) acceptance criteria (or conditions of satisfaction) for features they are going to accept into the iteration.
• Team members decompose features into low level tasks with full breadth to deliver the features to a level whereby all of the Product Owner’s conditions of satisfaction are met and the Definition of Done is satisfied.

Why use it?

• Sets up the entire team for success throughout the iteration. Teams tend to focus on goals and activities more, when an end-date (deadline) has been set, by which the work needs to be completed. Keeping the overall iteration goal in mind, it keeps the team focused and ensures progress throughout the project.
• Provides aligned and shared understanding of features to be worked on.
• Provides a focus session of collaboration between all team members to determine all work tasks required to deliver the features into the next increment on the product.
• A short burst of intense focus to build confidence across the team in their ability to achieve the next outcome and provide a space to collaborate to achieve this.

How to do it?

• A typical iteration ranges between 1 and 4 weeks. At the beginning of an iteration, the team will hold a planning meeting to discuss and to break down features into tasks.
• On average an iteration meeting will take around 1 hr for an iteration of 1 week. Subsequently, an iteration meeting would take on average 2 hours for an iteration of 2 weeks.
• Coming into the meeting, the product owner will have a prioritised product backlog. Each feature will be discussed with the DevOps team, and the group collectively estimates the effort involved. The team will then make an iteration forecast, outlining how much work the team can complete from the product backlog. The features of work then become the iteration backlog.

INPUTS:

• Identified set of prioritised and defined User Stories from the Product Owner to the team
• Capacity – Who is available, Are there any holiday, big meetings, etc during this period
• Velocity – How much has the team been able to produce recently
• Feedback ,Retro Actions and training – What else could provide value?

AGENDA:

• Independently review the Prioritised User Stories
• Each person will have 5 minutes to ask last minute questions
• Each person choose an story they will own (can work with other team members)
• Each person will have 5 minutes to share the stories they will complete in the next sprint and how they relate to the priorities.
• The group should call out gaps/concerns

OUTPUTS:

• Closed out previous Sprint. Load what seems to be an appropriate and agreed upon amount of stories for the next Sprint.

Tips for remote working

• Works quite well remotely but preparation is key.
• Ensure backlog refinement has taken place and backlog is in good order, that mean cards are compliant to the definition of ready and in a prioritised order.
• Prepare virtual tool in advance. Have as much information and working spaces created and displayed as possible e.g.
  • Sprint goal space
  • Team calendar space
  • Team velocity displayed
  • Parking lot space etc.
• Use a virtual timer to timebox discussions.
• Utilize online tools for estimation and sizing.
• Discussion can be a little harder so the facilitator is key to keep discussion on track and to make sure everyone gets involved and contributes.
• One person can be the facilitator and everyone’s should co-edit. Make this clear at the beginning of the meeting.
• Record the output of the session as summary of agreed goals and commitments, the stories and their breakdown and make it available to everyone.
• Cameras on.
• Take regular breaks.

Related Links

1. https://www.scrumguides.org/scrum-guide.html#events-planning