Search

Don't Mess with Scrum

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.


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.