What is the ‘Navigating the Scrum Events’ Series?
If you or your team are new to Scrum, you can use this as a starting point to answer, “what should we be doing and why?” for each Scrum Event. If your team is more experienced but you feel like you’re drifting away from healthy behaviors and patterns and you’re not sure how to course correct - you can use this series as a baseline to reset and start re-aligning your team. This is NOT the end-all-be-all perfect way to operate for all scenarios - but a straight-to-the-point tactical list of steps to help you get to the basic outcomes you need at the end of the event.
The Sprint - What’s The Point?
The Scrum Guide is incredibly concise (just 315 words in the English version) in communicating the purpose and value of the Sprint. I am going to expound on a few lines of this to help frame the rest of the Navigating The Scrum Events series. The purpose of the Sprint itself is a container for all of the other events and to “enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.” This time limit has an explicit purpose — “to generate more learning cycles and limit risk of cost and effort to a smaller time frame.”
The Scrum Guide also defines four bullet points that are deceptively dense with purpose:
During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality does not decrease;
- The Product Backlog is refined as needed; and,
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
The Sprint is One Month or Less
The highest level purpose of Scrum is to help people and teams deliver value incrementally in a collaborative way. Limiting the maximum time between formal events for collaboration, feedback, inspection and adaptation with your stakeholders helps shorten the feedback loop and keep the team (and organization) focused on the goal of delivering value as soon as possible.
If your team is able to create a usable increment in a shorter time-box than 1 month, consider shortening your Sprint cadence. You can create multiple increments within one Sprint, but tightening the feedback loop will allow faster reaction, more learning over time, and more iteration toward maximizing the value your team is creating.
Check out the What is Scrum? page to learn more.
Quality Does Not Decrease
In the pursuit of creating an increment, this important element of the Sprint is often overlooked. The Definition of Done is the commitment of quality for each Increment, and an important piece of the transparency of Scrum. There are many great resources available on the Definition of Done, a few of my favorites are:
- What is a Definition of Done?
- Sumeet’s Blog on Understanding the Definition of Done
- Martin’s Blog on Getting started with a Definition of Done
- Lavaneesh warns of some Dysfunctions to avoid with your Definition of Done
The Product Backlog is Refined as Needed
This is often misconstrued as a mandate to hold a Refinement Meeting every Sprint. Rather, this is addressing the reality that items on the Product Backlog are often large or nebulous. The intent is that the Scrum Team needs to work together to accomplish an outcome - that just enough of the Product Backlog is broken-down and defined well enough to enable a healthy working session at the next Sprint Review and the next Sprint Planning. Refinement can happen on an ongoing basis, as needed, in a meeting or may not be needed every Sprint depending on how Product Backlog items are defined and how the team is working. Figure out what is best for you. Jasper dives deeper into this in his blog Product Backlog Refinement is a Scrum Team Responsibility.
Scope May Be Clarified and Renegotiated with The Product Owner
Another common misconception is that the Sprint Backlog is a static or frozen artifact when Sprint Planning is finished. The Sprint Backlog contains three basic elements:
- The Sprint Goal - which is the “why” behind the Sprint
- A set of Product Backlog items - which are the team’s current best guess at “what” they will need to do in order to achieve the Sprint Goal
- An actionable plan for delivering the increment - which is the team’s current best guess at “how” they will go about creating the “what” and achieving the Sprint Goal.
Two of these three things are dynamic - the “what” and “how” are updated and adjusted throughout the Sprint as the team discovers new things and learns more about the complexity and unknowns of the work they are doing. The contents of the Sprint Backlog, and sometimes the specific requirements or acceptance criteria of items on the backlog can be adjusted or updated in collaboration with the Product Owner. Coming out of Sprint Planning you need the Sprint Backlog well enough defined for the team to get started, and the rest of the “what” and “how” can evolve as work progresses and the team learns from the work. All of this is in direct service of achieving the Sprint Goal.
No Changes That Would Endanger the Sprint Goal and Sprint Cancellation
The Sprint Goal is the element that doesn’t change after Sprint Planning. The Sprint Goal is the “why” you are doing the Sprint. The Sprint Backlog also encompasses the “what” and “how” the Scrum Team is planning to do in order to fulfill the “why”. This is related to the Scrum Value of Focus. If a team is constantly having their Sprint Goal changed, the historically proven result is minimal value ends up being created.
If circumstances arise that make the Sprint Goal obsolete - then the Product Owner has the authority to cancel the Sprint. Remember that obsolete means the outcome (the “why”) is no longer valuable to the stakeholders - not that the team no longer thinks they can achieve it by the end of the Sprint. Many teams and organizations struggle to define Sprint Goals as outcomes or “why” goals. If you are in the habit of writing output or “what” based goals - check out the many great resources available on Sprint Goals.
A Final Thought on Navigating the Scrum Events
The Scrum Guide is a lightweight framework - not an explicit list of steps of every action you should take. As the Scrum Guide itself states:
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.
The rest of this series is my opinion - my generalized tactical starting point with a team and organization new to Scrum (or a team that has identified they are in need of a reset). This is offered with no context on your team and organization’s reality. My experience fulfilling the Scrum Master accountability for many different teams has helped me understand that the core design and ideas of scrum are what is important. The rest of this series will describe the outcome that you are looking for at the end of each event. If the tactics I describe don’t help you get that outcome - you need to adjust and find what works for you!
Inspect and Adapt
The Sprint event, and all the events within it, are explicitly designed to create opportunities to inspect and adapt. You are not only inspecting and adapting “what” you are doing, but also the “why” and “how” you are doing it. This “how” includes how the Scrum Team is working together. This series should equip you with a starting point of how to get to the outcomes of each event - but if you are just going through the motions - over time you might fall victim to becoming stuck in Mechanical Scrum! Inspect and adapt how your team is working together and continue to strive toward living the Scrum Values and true Professional Scrum.