Introduction

The Sprint Planning is a collaborative session to

• Define the sprint goal
• Identify the stories, technical debt, defects that the team shall commit in a given sprint.
• Identify the corresponding tasks and acceptance tests required for the ones committed.

Pre-requisites for Sprint Planning session

• Release Plan – Prioritized list of items for a given release that includesTeam’s availability for the next 2 weeks to 1 month (Capacity planning)
  • Stories with story points (optional)
  • Defects with defects points (optional)
• Start & End dates for the Sprint

Stories and acceptance criteria are discussed and refined during a product grooming session a few days to less than a month prior to the Sprint Planning meeting. Since stories and acceptance criteria can change, gathering ‘Just Enough’ information a month in advance may be sufficient.

Participants for Sprint Planning Meeting

Your team comprising of:

• Developers (including any technical support from external vendors, etc.)
• Testers (Functional and Performance)
• Product Owner
• Product/Business Analyst
• Technical/Solutions Architect
• Interaction/Visual Designers

Consider reserving a conference room, projector, smart board, conference phones, software for sharing of desktops, etc. A typical planning session for a two-week sprint, could last between one to two hours. Efficiency and collaboration within teams tend to decrease for meetings longer than three hours.

Determine the Sprint Backlog – What needs to be done?

Identify and commit to stories/defects that can be accomplished in a given two-week sprint.

The Sprint Planning begins with the Product owner describing the roadmap and the proposed release meeting the product goals.

The Product owner and the team would typically discuss the nature of a release during Sprint Zero. Teams that use a shorter sprint zero (an hour or less than a day) may choose to discuss this during the first sprint.

A release may be categorized as

• Fixed scope/features (Work remains constant. Ex: Need to deploy a minimum set of features, say top ten stories from the product backlog. The team then determines the duration for completing it, identifying the corresponding number of sprints and the release date.)
• Fixed duration/deployment date (Time remains constant. Ex: Need to deploy at least a few features once a month or deploy. This may include a few ‘Nice to have’ features. Note, some teams may perform a shadow release which may expose new features to the end-users, but may reside on production environment.)
• A combination of fixed scope and deployment date (Ex: Need to deploy all ten stories within 4 weeks.)

Steps:

1. The Product owner reads out each story and the acceptance criteria from the release plan.
2. The team identifies the stories that can be completed in the current sprint and those that need to be performed in one or more subsequent sprints.
3. The team including the architect would discuss briefly the feasibility of completing the stories in the current sprint, retaining the remaining in the backlog for a future sprint or release. These discussions are primarily time-boxed, without getting too detailed in describing the solution or design details.
4. Upon identifying the collection of stories/tasks for the sprint, each team member provides his/her preliminarycommitted for completing these stories in the current sprint. This defines the Sprint Backlog for the current sprint. Each team member provides a final commitment once the corresponding tasks have been identified.

Identify tasks – How will the team achieve the work?

The first prioritized story from the sprint backlog is presented to the team.

Team members along with the technical and solutions architect, discuss the activities required for completing the story and begin writing the corresponding tasks. Remote participants might share their feedback over the phone or through instant messaging. Discussions for each story are time-boxed, ensuring that the team doesn’t dwell much into design and solutions.

For each story, the team identifies tasks that may include one or more domains –

• Database
• Development
• Updating any designs and layouts
• Unit testing
• Functional testing during the working sprint
• Performance Testing
• Code reviews
• Reviewing work in-progress with any external stakeholders
• Updating documentation
• Preparing and updating release notes
• Addressing medium and low priority defects

Tasks may be written on colored sticky notes, for teams that use a physical scrum wall. This makes it easier for the team to identify their tasks especially during the daily stand-ups.

Closing of the Planning session

The team commits to the final list of stories identified in the sprint backlog.

• Each member of the team has had a chance to review all tasks for all stories before providing his/her commitment.
• The team (including the product owner) reviews the definition of done for all stories in the sprint backlog.
• Any dependencies and assumptions are verified and captured.
• Team verifies that each story/defect in the Sprint Backlog has at least one task.