Scrum Foundations Course – Scrum Events

Scrum Events

Next: Sprint Planning

As we learned in a previous section, Scrum is an empirical approach to managing work. That means that each of the Scrum events is meant to increase transparency, so that the team can reliably inspect their progress, and adapt their plans to better reach a desired outcome.

In this section, we’ll get an overview of how all of the Scrum Events work together as a system. In future sections, we’ll take a closer look at each event, covering the why, who, and how in more detail.

The Sprint is the heartbeat of Scrum. It can be viewed as a container for all of Scrum’s inspect and adapt loops. The Scrum Team delivers a new iteration of the working product every Sprint. Each Sprint lasts – at most – one calendar month, and shorter Sprints are extremely common.

At the beginning of the Sprint, the Scrum Team comes together in the Sprint Planning meeting to assess which items from the top of the Product Backlog they can pull into the Sprint. The team crafts a Sprint Goal, a high-level objective that will be accomplished by delivering the selected Product
Backlog items. The Sprint Goal helps ensure a shared understanding of the purpose of the work in the coming Sprint.

They then create the Sprint Backlog, which is the Development Team’s plan for how they will deliver the new product Increment. Once Sprint Planning is complete, the Development Team begins their development work, which continues until the end of the Sprint. Once a day, they will meet together at
the Daily Scrum meeting to inspect the Sprint Plan and make any adaptations necessary. When the Sprint is complete, they will deliver a releasable product Increment. They inspect that Increment, along with other stakeholders, at the Sprint Review meeting, and adapt their future plans for the product by updating the Product Backlog. Finally, the Scrum Team will hold a Sprint Retrospective to inspect the system of work itself, and make adaptations to be more effective in future Sprints.

Scrum Teams should have consistent Sprint lengths. Sprints provide a rhythm to the work of the team and the business.

Instead of adjusting the length of each Sprint to match the upcoming work in the Product Backlog, effective Scrum Teams learn to refine Product Backlog items such that several can fit in any given Sprint.

The maximum Sprint length is one calendar month, and the majority of Scrum Teams today use two week Sprints, providing twice as many opportunities to inspect and adapt over time.

No new work can be pushed into the Sprint. In Scrum, the only way for work to be part of a Sprint is for the Development Team to pull it in. As discussed earlier, this is one of the primary purposes of the Sprint Planning meeting.

If a development team finds that they have additional capacity while the Sprint is in progress, they may choose to pull additional work into the Sprint. At all times, meeting the Sprint Goal is the guiding principle.

If, as is more common, the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

The Product Owner may choose to cancel a Sprint. This might happen if, for example, the Sprint Goal becomes obsolete, market conditions change, or the company makes a major strategy change. Sprint cancellations are rare since Sprints are intentionally short.