How to Establish a Sprint Plan

Introduction The Sprint Planning is an essential part of the Sprint and have two objectives:

  • Decide what will be delivered in the Sprint – the Sprint Goal.
  • Decide what activities are needed in order to achieve the Sprint Goal.

The Sprint Planning session is typically 1 day for a 4 week Sprint and relatively shorter for a shorter Sprint. The result is a Sprint Plan, which lists all the activities the Scrum Team has to perform, but the plan only have a schedule for the activities to perform the first couple of days of the Sprint. The remaining activities is scheduled on the fly in the Daily Sprint ensuring a couple of days forecast of activities to be done.
Who will participate? The planning has the Scrum Team as mandatory participant, i.e.:

Beside these participants Business representatives or Subject Matter Experts (SME) may be invited to provide important information needed to establish a trustworthy plan. The participants have the following responsibilities:

Product Owner Development Team Scrum Master Business SME’s
Ensure the Scrum method is
followed		 I I A/R I/C I/C
Resolve ambiguities in the User Stories A R C I/C I/C
Create the Sprint Plan C A C I/C I/C
Legend: R=Responsible; A=Accountable; C=Consulted; I=Informed

What is the input The Sprint Planning can start when:

  • The Scrum Team is establish.
  • The Release Backlog is ready.
  • The project setup is ready, e.g. funding, location, tools, etc.
Which tasks are expected The Scrum Team is expected to perform the following tasks:

Task Description
Prepare Planning The Sprint Planning is a collaborative effort for the entire Scrum team.The Product Owner present the Release Backlog for the Scrum Team and explain the business preferences.
The Scrum Master briefly present the rules for the planning and what need to be in the plan in order to adhere to company or regulatory requirements.
The result of the planning is documented for monitoring and control of progress during the Sprint in the Daily Scrum.
For how to document the plan – please see the “Documenting the Plan” task below.
Selecting a User Story for the Sprint The Development Team select a User Stories from the “top” of the Release Backlog. The User Stories is verified to adhere to the criteria expressed by INVEST in order to be fit for development.
If the User Story do not adhere to the INVEST criteria, e.g. there is doubt about the interpretation of the User Story the Development Team consult the Product Owner, who either resolve the problem or involve someone who can.
The Development Team and the Product Owner jointly redefines and agree to the criteria for a Done‘ User Story.Note: It is not necessarily the entire team who plan implementation of a User Story. The team can break up in smaller groups and each group select the User Story they prefer to plan implementing.
Define activities to implement the User Story The Development Team identify the Good Engineering Practices needed to implement and demonstrate that the solution meets the criteria for being ‘Done’.
The Development Team analysis the risk associated with errors in the implementation of the selected User Story. If any risk is identified, the team defines mitigating actions to reduce the risk to an acceptable level.
Based on the development activities and the mitigating actions the team estimate the effort required to produce a ‘Done’ product.
The mitigating actions, the development activities and the estimate is noted together with the User Story.
Create the Plan for the Sprint The Development Team and the Product Owner repeats the steps:

  • Selecting a User Story for the Sprint.
  • Define activities needed to implement the User Story.
  • Estimate the effort to implement the User Story.

until approximately 80% of time available for the Sprint is assigned to implementing User Stories.
The remaining 20% is saved for the Daily Scrum, configuration and change management, the Sprint Review, the Retrospective and contingency.
When all User Stories are implemented and there is still remaining time in the Sprint, then the team can select additional User Stories from the Release Backlog for implementation in the Sprint.
Documenting the Plan
There are many different ways to document the plan based on the notes from the above activities. The plan can be documented e.g.:
  • In a traditional plan document, e.g. a Word document.
  • In a tool – e.g. in MS Project, Azure DevOps or something more sophisticated.
  • On a whiteboard, using Post-It to note activities and estimates for each User Story.
  • Kanban board, using Post-It to note activities and estimates for each User Story.

How shall the result be controlled? The Scrum Team perform a critical walk-through of the plan at the end of the planning session asking the question – will we commit to this plan, is it doable?
If the answer is “Yes” then the plan is basis for the work in the Sprint.
What is the output The output is a plan in a format selected by the Scrum Team.
If the product is for an regulated industry e.g. health care, the plan need to be stored in a durable form. This can be done by taking a photo of the Whiteboard/Kanban Board and save it. This is most easily done by embedding it in e.g. a Word Document.
The final document is supplemented with the needed administrative information, e.g. heading, document number, electronic signature, etc.
Note: the time stamp on the photo of the Whiteboard or Kanban Board is evidence for when the plan was made.
When can we exit The Sprint Planning process is terminated when there is a plan the Scrum Team has committed itself to and it is documented as required by the context the product is developed in.
Hints and Examples Example of a plan on a Kanban Board.
Example of a plan on a Whiteboard.
…