Sprint execution

This document defines how to execute each sprint.

Prerequisites

  • The people involved are the product owner (or product manager), scrum master and development team.

Sprint workflow

  1. Hold a sprint planning meeting before starting the sprint.
  2. Carry out daily work.
  3. Carry out product backlog refinement during the sprint.
  4. Conduct a sprint review at the end of the sprint.
  5. Conduct a sprint retrospective at the end of the sprint.

Sprint planning meeting

Pre-preparations

  1. Close the sprint before the last one.
  2. Create a new sprint and move the previous stories, which could not be closed, to the new sprint.
    • Do not simply move the stories but recreate them as stories indicating the actual situation.
    • New stories may occur in this process.
    • For example, remaining confirmation tasks could be handled by creating the story “Confirmation of sprint XX” and transferring the tasks there.

Part 1

Participants: Product owner (or product manager), scrum master, development team
Duration: 2 hours (for a two-week sprint)

  1. The schedule of the new sprint is announced by the product owner and input.
    • Sprints should generally be two weeks, or one week for an inexperienced scrum team.
  2. The development team indicates story points that will be covered in this sprint. This should generally be the same as the results of the previous sprint.
  3. The scrum team sets objectives to be accomplished during the sprint (sprint goals).
  4. The development team selects the stories necessary to accomplish the sprint goals according to the backlog and inputs them in the sprint backlog.

Part 2

Participants: Scrum master, development team
Duration: 2 hours (for a two-week sprint)

  1. Allocate a manager for each story.
  2. Create specifications and a checklist for each story. Ask the product owner (or product manager) about any points you are unsure of in any story.
  3. Decide on the content to be demonstrated for each story at the sprint review.
  4. The story managers indicate all of the tasks that are needed in order to complete each story in the sprint backlog, based on the check results (around 15 minutes).
    Reference: Criteria for good tasks: SMART
  5. Once the tasks are set, check that there are no issues in any tasks and enter estimated times for each task.
    • Each task must be small enough to complete in one day.
      • If experience indicates that around five hours of work can be completed with no overtime, this is the ideal amount of work per day converted into real time.
      • Therefore, any task that takes longer than five hours needs to be divided up.
  6. If the time required for a task cannot be estimated and other work depends on this task, the task should be added to impediments, rather than adding a buffer to the time estimate.
  7. Look at the total estimated time and judge whether the work can be completed during the sprint. Consult the product owner (or product manager) if there is a risk that it cannot be completed.

Daily work

  1. Hold daily scrums.
    • These documents presume that these will be held in the morning, but they can be held at any time.
    • Even if they are not held in the morning, daily scrums need to be held at the same time and in the same place every day.
  2. Open the Kanban and move today’s tasks (indicated at the daily scrum) to “Doing”.
  3. Each pair discusses their tasks, decides which tasks will be done by each member and which will be done together and then begins working on their tasks.
  4. Move each task to “Done” when it is completed.
  5. If any tasks are still in “Doing” at the end of the work day, update the working time and remaining time and return the tasks to “ToDo”.
    • Make sure not to leave any tasks in the “Doing” lane at the end of the work day.

Product backlog refinement

Participants: Product owner (or product manager), scrum master, development team
Duration: Around 5 hours in total throughout the sprint period (for a two-week sprint)

The stories for the next 2-3 sprints need to be refined. Do not refine later stories, as it is difficult to picture them, which means that they may need to be changed.

  1. Add stories. Follow the instructions for creating product backlog in the overall sprint plan when adding stories.
  2. Revise existing stories and add more details. Check whether the revisions based on the story splitting cheat sheet are sufficient.
  3. Revise the priority order of the stories.
  4. Check that each story is ready.
    • At minimum, the backlog expected to be executed in the next sprint should be ready.
    • If the stories are not ready, talk to the team about preparing them during the previous sprint or revise the completion conditions.

Sprint review

Participants: Product owner (or product manager), scrum master, development team
Duration: 2 hours (for a two-week sprint)

Pre-preparation

  • Display the screen where the demonstration will be performed, along with the backlog and Kanban.

Review

  1. Announce that a review is being conducted for sprint X.
  2. Provide a demonstration for each story.
  3. Ask for any opinions.
    • A representative records any opinions in the minutes. When there are no more opinions, proceed to the next step.
  4. Instruct the minute-taker to read the minutes aloud.

After the review

  • The minute-taker adds opinions from the review to the backlog and/or bugs.

Sprint retrospective

Participants: Product owner (or product manager), scrum master, development team
Duration: 1.5 hours (for a two-week sprint)

  1. Hold a sprint retrospective.

After the retrospective

  • Add points to try to the project wiki.