A Summary of the 10 Scrum Myths

Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In a series of posts we — your ‘myth busters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are byThea Schukken. 

About 3 months ago Barry Overeem and I started writing the "Scrum myth busters" series. So far we've addressed 10 persistent myths. We're definitely not done yet; our backlog contains about 10 more myths we'll try to bust. However, because it might be difficult to keep track on all these different myths, we wanted to offer you an overview and summary of myth 1 - 10. Enjoy the overview, meanwhile we'll continue writing Scrum myth #11.

1. The Scrum Master must be present during the Daily Scrum

In this blog post, we’ve described the myth that the Scrum Master should always be present during the Daily Scrum. We’ve offered the perspective from the Scrum Guide, described some examples of possible problems in how Scrum is applied and shared tips & tricks on how to make the Daily Scrum more effective. The take-away is that the Scrum Master ensures that a Daily Scrum takes place, but the Development Team is responsible for conducting the meeting.

2. The Sprint Backlog can’t change during the Sprint

In this blog post, we’ve described the myth that the Sprint Backlog is fixed during the Sprint. We’ve busted this myth by offering the perspective from the Scrum Guide and describing the difference between forecast and commitment.

Take-aways:

• Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not.
• The Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.
• Embrace the emerging nature of the Sprint Backlog.

3. Releases are done only at the end of the Sprint

In this post we discussed the myth that Scrum Teams at best release working software at the end of a sprint, constraining teams that are capable of releasing faster. In this post we showed that the Scrum Framework actually encourages teams to improve their process, infrastructure and practices to the point where releases can be done throughout the Sprint. This maximizes the quality of the feedback of the empirical process that Scrum tries to implement. We also offered a few tips to help you move towards this point.

Take-aways:

• The completeness of the increment is defined by the amount of time that is still needed to get the increment to users (e.g. to production).
• The Sprint represents a minimal boundary for when to deliver a “Done” increment.
• The more “Done” the increment is, the more useful the feedback will be that is gathered during the Sprint Review.

4. The Product Backlog has to consist out of User Stories

In this post, we’ve busted the myth that a Product Backlog has to consist entirely out of User Stories. By describing the purpose and characteristics of the Product Backlog, we also busted the related myth; that User Stories are an inherent, necessary part of Scrum.

There’s absolutely nothing wrong with User Stories. They are a great technique for capturing functional requirements in a ‘good enough for now’-manner that leaves room for further conversation. But Scrum doesn’t prescribe nor require them. Other techniques are fine, as long as they help promote three things:

• They make the Product Backlog understandable to the Scrum Team and its stakeholders.
• The level of detail they demand should fit the uncertainty of product development.
• They should foster an ongoing communication and conversation between the Scrum Team and stakeholders (which includes users);

5. The Product Backlog is prioritized

In this post, we busted the myth that the Product Backlog is ‘prioritized’. Although a seemingly trivial change of wording, the Product Backlog is ‘an ordered list’ instead. By framing the Product Backlog as a ‘prioritized list’, we shortcut the active role that a Product Owner needs to play. He or she is responsible for continuously (re)ordering the Product Backlog to maximize the value delivered each Sprint as work progresses and insights emerge. As a closing, we offered a few tips to help you understand the Product Backlog in a broader sense.

Take-aways:

• The focus on ordering (over ‘prioritization’) underscores the active role that the Product Owner continuously has to play in the ordering and reordering, of the work in a manner that maximizes value.
• By framing the Product Backlog as a prioritized list, we oversimplify the role of the Product Owner.
• There are countless factors that influence the potential ordering of a Product Backlog, including dependencies, risks, knowledge, costs, business conditions, cost of delay etc.

6. The Product Owner is a Proxy for Stakeholders

In this post, we busted the myth that the Product Owner is a proxy for stakeholders. The bottom-line is that Scrum Teams become significantly less Agile when only the Product Owner communicates with stakeholders. Instead of framing the Product Owner as a proxy, we instead prefer to explain the Product Owner as the person responsible for including stakeholders in the conversation. We offered a few concrete tips on how to do this.

Take-aways:

• Scrum is a process of ‘collaborative discovery’
• The Product Owner is responsible for including the voice of the stakeholders in the process of ‘collaborative discovery’

7. The Scrum Master Must Resolve Every Problem

Today we busted the myth that the Scrum Master is responsible for solving all problems that hinder the Development Team in achieving the Sprint Goal. Instead, the Scrum Master should help the Development Team to become increasingly capable of resolving similar problems on their own (self-organization). The Scrum Master does so by addressing those problems that ‘act as a parachute’ to the team slowing down overall progress, not just whatever pops up. In this post we offered a couple of concrete examples and clarified what kind of problems a Development Team should solve, and what problems are ‘impediments’ to be picked up by the Scrum Master. We also offered some tips on how to do this.

Key take-away:

• “A Scrum Master should reveal, not resolve.”

8. The Scrum Master is a Junior Agile Coach

In this blog post we’ve busted the myth that “The Scrum Master is a junior Agile Coach”. Effective change is driven from “the inside-out”. The Scrum Master – being part of the Scrum Team – is in a better position to facilitate this change than an (external) Agile Coach. This is also how the Scrum Guide intended the role of the Scrum Master.

When organizations choose to implement an empirical process primarily through Scrum, there should be almost no need for Agile Coaches. Instead, Scrum Masters should be enabled and supported to promote the empirical process on all levels of the organisation. If they can, and if they do, no other roles are necessary to help organizations generate valuable outcomes through Scrum.

Take-aways:

• “A good Scrum Master helps a Scrum Team survive in an organisation’s culture. A great Scrum Master helps change the culture so Scrum Teams can thrive.” – Geoff Watts
• “The Scrum Master enables change from the inside out.”
• “The chances of successful Scrum adoption will increase drastically when you consider your Scrum Master as the true “inside out” change facilitators!”
• “When organizations choose to work with the Scrum, there should be no need for Agile Coaches.”
• “The reality is that most Agile Coaches are junior Scrum Masters.”
• “Organisational change should be driven from the inside-out by people that are truly part of the teams.”

9. Story Points are Required in Scrum

In this post, we busted the myth that Scrum requires work to be estimated in Story Points. Although it is a useful technique, and used by many Scrum Teams, it is by no means the only technique. We used this post to describe some alternatives and to explain why Story Points became prevalent. By doing so, we also explained how estimation fulfils a different role in Scrum than compared to plan-based approaches.

Above all, remember the quote by Esther Derby: “Estimating is often helpful, estimates are often not.” The more complex the activity at hand, the more important communication and collaboration gets.

Take-aways:

• “Use the empirical process of Scrum to capitalize on change rather than control against it.”
• “Time-based estimates uphold the illusion of accuracy and predictability.”
• “Respect the complexity of software development, and don’t let estimation replace the importance of empiricism itself.”

10. In Scrum, there is no planning

In this post, we busted the myth that there is no planning, and there are no plans, in Scrum. As it turns out, there is a lot of planning going on. The various Scrum Events also generate quite a number of plans, expressed through (amongst others) the Product Backlog, the Sprint Backlog and the Definition of Done. The plans we create in Scrum are different from what we traditionally understand as plans; hefty documents that provide detailed, step-by-step descriptions of what is needed. Instead, the focus is on planning as an activity to create a shared understanding of what to do next.

Although it is sometimes said that “planning is useful, plans are not”. We feel that this reinforces the myth by underscoring that plans are always bad. In this post, we showed that plans are useful, as long as they respect the complexity and unpredictability of product development. A more accurate statement would be:

"Planning is useful. Plans are helpful. Detailed plans are a waste of time."

Take-aways:

• Planning needs to be a collaborative effort between everyone involved.
• Whenever we talk of plans in Scrum, we talk about plans as “shared understanding”, not as “documents”.
• Scrum Events are the minimal moments where planning takes place.
• In the complex environment of product development, where change is continuous, detailed plans are a form of waste.

Closing

In this article we offered an overview of the 10 Scrum myths we've busted so far. We're definitely not done yet; our backlog contains about 10 more myths we'll try to bust. And we're open for suggestions, so if you have a myth you'd like us to bust (or not), let us know. However, because it might be difficult to keep track on all these different myths, we wanted to offer you this summary. Enjoy reading, meanwhile we'll continue writing Scrum myth #11!

Want to separate Scrum from the myths? Join our Professional Scrum Master or Scrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses.