Rituals

Prescribed events, or rituals, are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Scrum uses time-boxed events, such that every event has a maximum duration. This ensures an appropriate amount of time is spent planning without allowing waste in the planning process.

Other than the Sprint itself, which is a container for all other events, each ritual in Scrum is a formal opportunity to inspect and adapt something. These rituals are specifically designed to enable critical transparency and inspection. Failure to include any of these rituals results in reduced transparency and is a lost opportunity to inspect and adapt.

Scrum Rituals are usually attended by both Pigs (committed) and Chickens (invovled). While the Chickens can provide input on topics, Pigs get the final say.

The Sprint

Pigs: Development Team, Scrum Master, Product Owner

Chickens: Business Stakeholders

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

 

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Backlog Grooming

Pigs:  Product Owner

Chickens: Development Team, Scrum Master

Since Product Backlog Items are quite often large and general in nature, and since ideas come and go and priorities change, Product Backlog Grooming is an ongoing activity throughout a Scrum project. This activity includes but is not limited to:

  • keeping the Product Backlog ordered;
  • removing or demoting items that no longer seem important;
  • adding or promoting items that arise or become more important;
  • splitting items into smaller items;
  • merging items into larger items;
  • estimating items.
     

One key benefit of the Product Backlog RGrooming activity is to prepare for the upcoming Sprints. In aid of this, the grooming activity gives special attention to preparing items that are coming up for implementation. There are many things to consider, including but not limited to:

  • Each item entering the Sprint should ideally represent an increment of "business value".
  • The Development Team needs to be able to build each item within a single Sprint.
  • Everyone needs to be clear on what is intended. 

Depending on the nature of the product, other skills and inputs may be needed. In every case, Product Backlog Grooming is best considered as an activity for all the team members, not just the Product Owner.  

Sprint Planning

Pigs: Development Team, Scrum Master

Chickens: Product Owner

The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team. The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.

 The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration. The two parts of the Sprint Planning Meeting answer the following questions, respectively:

  1.  What will be delivered in the Increment resulting from the upcoming Sprint?
  2. How will the work needed to deliver the Increment be achieved?

 

Part 1

In this part, the Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming sprint.

 

Part 2

Having selected the work of the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

 The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during the Sprint Planning Meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint.

 The Product Owner may be present during the second part of the Sprint Planning Meeting to clarify the selected Product Backlog items and to help make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the Sprint Backlog items with the Product Owner. The Development Team may also invite other people to attend in order to provide technical or domain advice.

 Daily Scrum

Pigs: Development Team, Scrum Master

Chickens: Product Owner

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains:

 

  • What has been accomplished since the last meeting?
  • What will be done before the next meeting?
  • What obstacles are in the way?

  Sprint Reviews

Pigs: Development Team, Product Owner

Chickens: Business Representatives and Stakeholders

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an
informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. For example, two week Sprints have two-hour Sprint Reviews.

The Sprint Review includes the following elements:

  • The Product Owner identifies what has been “Done” and what has not been “Done”;
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

 Sprint Retrospectives

Pigs: Development Team, Scrum Master

Chickens: Product Owner

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.