By the dynamic duo of Christiaan Verwijs and Barry Overeem. We’re still unsure who is Batman and who is Robin in this configuration.

A Summary of the 10 Scrum Myths

Christiaan Verwijs
Jan 5, 2018 · 9 min read

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 by Thea 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.

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).

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.

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.

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’

7. The Scrum Master Must Resolve Every Problem

In this post 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

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.”

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 (among 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.

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 Professional Scrum Master II courses. We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Or check out the previous episodes here.


The Liberators

The Liberators: Unleashing Organisational Superpowers

Christiaan Verwijs

Written by

I aim to liberate teams & organizations from de-humanizing and ineffective ways of organizing work. Professional Scrum Trainer & Steward @ Scrum.org

The Liberators

The Liberators: Unleashing Organisational Superpowers

Christiaan Verwijs

Written by

I aim to liberate teams & organizations from de-humanizing and ineffective ways of organizing work. Professional Scrum Trainer & Steward @ Scrum.org

The Liberators

The Liberators: Unleashing Organisational Superpowers

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store