Scrum’s power is in its simplicity. Rather than containing a set of work instructions, Scrum is a framework offering general principles. That’s what makes it well-suited to complex environments where more is unknown than known.
The simplicity of Scrum means that teams can adopt the complementary practices that work for their environment. For example, Scrum doesn’t tell teams that they need to use points. Instead, Scrum directs teams to ensure they size higher-ordered Product Backlog items (PBIs) so they can complete them within one Sprint. How to do that is up to the Scrum team. Points, flow metrics, hours – all are legitimate options, and each has pluses and minuses. Scrum is not prescriptive because it relies upon the intelligence of those using it to figure out how to apply the framework to their specific situation.
But that doesn’t mean that teams should change the framework. Teams that change the framework are not using Scrum and are missing out on some of its benefits. The Scrum framework consists of 5 events, 3 accountabilities, 3 artifacts and five values. Today, we will talk about the order of the events in Scrum.
The order of events in Scrum matters. For example, holding the Sprint Retrospective for the previous Sprint after Sprint Planning for the next Sprint limits the team’s ability to adapt. As a result, the team misses the benefit of empiricism.
The Scrum framework is rooted in lean thinking and empiricism. Lean thinking reduces waste and focuses on the essentials. Empiricism means making decisions based on what is known. Empiricism has three pillars: Transparency, Inspection, and Adaptation.
Scrum events are opportunities for inspection and adaptation. At the Sprint Retrospective, the team inspects their interactions, their processes, and tools and brainstorms ways to adapt and improve in those areas. In many situations, the team will implement or consider those improvements at the next Sprint Planning meeting. By having the Sprint Retrospective for the previous Sprint AFTER Sprint Planning for the next Sprint, many of the potential improvements the team identifies at the Sprint Retrospective will be delayed by a Sprint – possibly more.
The diagram above shows the five Scrum Events. The Sprint begins with Sprint Planning and ends with the Sprint Retrospective. Each event depends upon the successful completion of the previous event to ensure that teams can inspect and adapt. If the Daily Scrum for a Sprint happens before the Sprint Planning event for that Sprint, the team can’t inspect their plan and adapt it because they don’t have a plan yet. If the Sprint Planning event for the next Sprint happens before the Sprint Retrospective for the previous Sprint is completed, the team can’t adequately plan for the upcoming Sprint. They don’t yet know what improvements they will be making to their interactions, processes, or tools for the upcoming Sprint.
The Scrum framework includes five values (Commitment, Focus, Openness, Respect, and Courage), three accountabilities (Scrum Master, Product Owner and Developer), three artifacts (Product Backlog, Sprint Backlog and Increment) and five events (The Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.)
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. That accountability includes ensuring teams understand the difference between complementary practices a team can use or modify based on their unique situation and those part of the Scrum framework that should not be changed.
Conclusion
The Scrum framework is easy to understand. Its simplicity supports complex work and the autonomy of team members in figuring out the details of how to deliver value each Sprint. But, each of the elements of the Scrum framework is important, including the order of events. Teams who mess with the framework are messing with Scrum. Don’t mess with Scrum! All of the values, accountabilities, artifacts and events are part of the Scrum framework for a reason. Any changes to the framework limit its effectiveness.