Scrum is simple, but that simplicity means that each of its elements is essential. The values, accountabilities, artifacts and events are all part of the framework for a reason. Teams that mess with the framework are messing with Scrum. Teams that make changes to the elements limit Scrum's effectiveness and aren't really using Scrum.
Below are some of the things in the Scrum framework teams shouldn't mess with but often do.
Timeboxes
Each of the Scrum events has a timebox, and that timebox is important. For example, the Daily Scrum has a 15-minute timebox, which means this event should never exceed that time. The Scrum Master’s responsibility is to ensure that team members understand the importance of honoring the timebox.
The table above provides an overview of the timebox for each of the 5 Scrum events. I confess that when I was a new Scrum Master for a small, co-located team, I frequently allowed the Daily Scrum to run into an hour-long debate. It didn’t take long for people to find reasons to be out of the room for this debacle or to tune out the discussion. As a result, we lost our focus and rarely adapted the Sprint Backlog based on the latest information. The team struggled to deliver a Done Increment each Sprint.
Don’t mess with the timeboxes. The purpose of the Daily Scrum is to quickly inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary by adjusting the upcoming planned work. Those who need further clarification and discussion - for example, to problem solve any blockers identified - should do so AFTER the Daily Scrum. Those discussions might be important, but it’s likely not necessary for the entire team to participate. By limiting the Daily Scrum to 15 minutes, the team increases efficiency and limits waste.
Remember that Daily Scrum is not the team’s only opportunity to collaborate. The team should continually collaborate as needed throughout the Sprint.
Accountabilities
The three accountabilities in Scrum are the Scrum Master, Product Owner and Developers. Clarity around each of these accountabilities is critical for a high-performing team. It’s very easy for the Product Owner to start encroaching upon the Developers’ responsibilities or for the Developers to begin to overstep into the Product Owner’s responsibilities.
For example, Developers on a Scrum Team are accountable for the Sprint Backlog. This means that Developers decide which Product Backlog items (PBIs) to pull into each Sprint. Sometimes, however, the Product Owner may demand that the team pull more PBIs than the team is comfortable with into the Sprint. Imagine a situation where the Product Owner has created and communicated a forecast that calls for completing certain PBIs by a specific date. If the team underperforms in one Sprint, the Product Owner may demand that the team pull MORE work into a subsequent Sprint to make up the time.
While a certain amount of push and pull is healthy (meaning that the Product Owner can and should ask for more), ultimately, the Developers own the Sprint Backlog and are accountable for determining which work to pull into the Sprint. If the Developers were to pull more work into the Sprint than they could reasonably expect to complete, it might impact their ability to deliver a Done increment that meets the Sprint Goal. Remember that a forecast is just an estimate - not a promise. Rather than risk the team’s ability to deliver a Done, valuable increment, the Product Owner might do better to update the forecast based on the latest information.
Below is a cheat sheet that shows the artifacts impacted by each Scrum accountability.
Scrum values
The five Scrum values are commitment, focus, openness, respect, and courage. These values are not just window dressing but an essential part of the Scrum framework. As the 2020 Scrum guide puts it, “When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.”
Scrum Teams that do not practice these values limit their ability to inspect and adapt. For example, all Scrum Team members need to be open to feedback at the Sprint Retrospective. The Developers might share input with the Product Owner about the clarity of the PBIs. The Product Owner should be open to that feedback and listen carefully to the Developers for how to improve PBI clarity and simplicity.
If your team struggles to live the values, discuss it at your next Sprint Retrospective. One way to do this is to place the five Scrum values on a shared whiteboard. Then, ask the Scrum Team to brainstorm how to better embody these values in their work or interactions with the parent organization or customer. Next, vote on one or two actionable improvements to implement as soon as possible.
The purpose of each event
Each event in Scrum has a clearly defined purpose, and each event builds upon the success of the previous one. It’s easy to confuse the purpose of each of the events. For example, the purpose of the Sprint Planning meeting is to lay out the work of the Sprint. This means that teams define a Sprint Goal, select which PBIs they aim to complete, and develop a plan for how to deliver them. The plan for delivering the selected PBIs is discussed in the Sprint Planning event, not during Product Backlog refinement. Many teams falsely believe that they should task out or fully plan how to deliver each Product Backlog item during Product Backlog refinement, but that is not the case. How a team delivers a PBI might change based on which other PBIs it selected for the Sprint.
Likewise, the purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. This is not a status meeting where the Developers update the Product Owner. Instead, it is a working session for the Developers.
The table below provides a quick overview of the purpose of each of the five events in Scrum.
Don’t mess with the events. Each Scrum event has a specific purpose, and each builds upon the previous event. Work with your Scrum Master to ensure that your team uses the events as designed to maximize their effectiveness.
Conclusion
It is Scrum’s simplicity that makes it so powerful. Rather than containing a set of work instructions, Scrum is a framework. That’s why it’s so well suited to complex environments, where less is known than known. The Scrum Master is accountable for helping team members and the parent organization understand the practices that are part of the Scrum framework and those that are complementary. The simplicity of Scrum means that teams can adopt the complementary practices that work for their specific environment. However, teams should never mess with the framework itself.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
- Applying Professional Scrum
- Introductory class for those new to Scrum
- Professional Scrum Master
- Geared towards Scrum Masters coaching teams
- Professional Scrum Master II
- Advanced class for Scrum Masters
- Professional Agile Leadership
- For leaders and managers of Agile teams
- Professional Scrum Product Owner
- For Product Owners
- Professional Scrum Product Owner - Advanced
- Advanced class for Product Owners
- Professional Scrum with Kanban
- For anyone interested in learning about implementing Kanban principles within a Scrum Team
- Scaled Professional Scrum with Nexus
- For three or more teams working together on a single product
Both public and private classes are available. To learn more, contact Rebel Scrum.
