Scrum Workflow

Sprint

A sprint (also known as iteration or timebox) is the basic unit of development in Scrum. The sprint is a timeboxed effort; that is, the length is agreed and fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.

Each sprint starts with a sprint planning event that establishes a sprint goal and the required product backlog items. The team accepts what they agree is ready and translate this into a sprint backlog, with a breakdown of the work required and an estimated forecast for the sprint goal. Each sprint ends with a sprint review and sprint retrospective, that reviews progress to show to stakeholders and identify lessons and improvements for the next sprints.

Scrum emphasizes valuable, useful output at the end of the sprint that is really done. In the case of software, this likely includes that the software has been fully integrated, tested and documented, and is potentially releasable.

Sprint Planning

At the beginning of a sprint, the scrum team holds a sprint planning event to:

• Mutually discuss and agree on the scope of work that is intended to be done during that sprint
• Select product backlog items that can be completed in one sprint
• Prepare a sprint backlog that includes the work needed to complete the selected product backlog items
• Agree the sprint goal, a short description of what they are forecasting to deliver at the end of the sprint.
• The recommended duration is four hours for a two-week sprint (pro-rata for other sprint durations)
  • During the first half, the whole scrum team (development team, scrum master, and product owner) selects the product backlog items they believe could be completed in that sprint
  • During the second half, the development team identifies the detailed work (tasks) required to complete those product backlog items; resulting in a confirmed sprint backlog
    • As the detailed work is elaborated, some product backlog items may be split or put back into the product backlog if the team no longer believes they can complete the required work in a single sprint
• Once the development team has prepared their sprint backlog, they forecast (usually by voting) which tasks will be delivered within the sprint.

Daily Scrum

Each day during a sprint, the team holds a daily scrum (or stand-up) with specific guidelines:

• All members of the development team come prepared. The daily scrum:
  • starts precisely on time even if some development team members are missing
  • should happen at the same time and place every day
  • is limited (timeboxed) to fifteen minutes
• Anyone is welcome, though only development team members should contribute.
• During the daily scrum, each team member typically answers three questions:
  • What did I complete yesterday that contributed to the team meeting our sprint goal?
  • What do I plan to complete today to contribute to the team meeting our sprint goal?
  • Do I see any impediment that could prevent me or the team from meeting our sprint goal?

Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved unfounded) identified in the daily scrum should be captured by the scrum master and displayed on the team’s scrum board or on a shared risk board, with an agreed person designated to working toward a resolution (outside of the daily scrum). While the currency of work status is the whole team’s responsibility, the scrum master often updates the sprint burndown chart. Where the team does not see the value in these events, it is the responsibility of the scrum master to find out why. This is part of the responsibility of educating the team and stakeholders about the Scrum principles.

No detailed discussions should happen during the daily scrum. Once the meeting ends, individual members can get together to discuss issues in detail; such a meeting is sometimes known as a ‘breakout session’ or an ‘after party’.

Sprint Review

At the end of a sprint, the team holds two events: the sprint review and the sprint retrospective.

At the sprint review, the team:

• reviews the work that was completed and the planned work that was not completed
• presents the completed work to the stakeholders (a.k.a. the demo)
• collaborates with the stakeholders on what to work on next

Guidelines for sprint reviews:

• Incomplete work cannot be demonstrated.
• The recommended duration is two hours for a two-week sprint (proportional for other sprint-durations).

Sprint retrospective

At the sprint retrospective, the team:

• reflects on the past sprint
• identifies and agrees on continuous process improvement actions

Guidelines for sprint retrospectives:

• Three main questions arise in the sprint retrospective:
  • What went well during the sprint?
  • What did not go well?
  • What could be improved for better productivity in the next sprint?
• The recommended duration is one-and-a-half hours for a two-week sprint (proportional for other sprint duration(s)).
• The scrum master facilitates this event.

Backlog refinement

Backlog refinement (formerly called grooming) is the ongoing process of reviewing product backlog items and checking that they are appropriately prepared and ordered in a way that makes them clear and executable for teams once they enter sprints via the sprint planning activity. Product backlog items may be broken into multiple smaller ones. Acceptance criteria may be clarified. Dependencies may be identified and investigated.

Although not originally a core Scrum practice, backlog refinement has been added to the Scrum Guide and adopted as a way of managing the quality of product backlog items entering a sprint, with a recommended investment of up to 10% of a team’s sprint capacity.

The backlog can also include technical debt (also known as design debt or code debt). This is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

From Wikipedia

Go back to ScrumAA Wiki homepage