Debunking Popular Scrum Myths

Eighty percent of people who are using agile today use some flavor of the Scrum Framework. As you can imagine, there is a lot of variance in how Scrum is applied, and some people who use Scrum in ways that are not recognizable. People make up rules and have had beliefs about Scrum that qualify as “alternate facts” or more politely, Scrum Myths.

If only there was a standard for Scrum.

But wait, there is a standard for the Scrum Framework and that is the Scrum Guide. The Scrum Guide is maintained by Jeff Sutherland and Ken Schwaber (the creators of Scrum) and it is considered the definitive reference for the Scrum Framework.

At only 19 pages, there is no reason not to read it. And internalize it. That is if you are among the 80% of agile practitioners who use Scrum.

Most Scrum users have never bothered to read the Scrum Guide. Hey, reading is overrated! They assume or project things into Scrum Framework (or not in it) based on what they want to believe. Or they don’t care what the guide says and they adjust Scrum in ways they think will make it work better for them.

Here are a few beliefs about Scrum or Scrum Myths that have come up recently:

1. You can conduct Sprint Reviews by email
2. Scrum says that you must have dedicated teams
3. The role of the Business Analyst is included in the Scrum Framework
4. Planning Poker is part of Scrum

Like the official fact-checkers in today’s political climate, I set out to actually read the Scrum guide and to confirm or debunk these Scrum beliefs.

Scrum Myth #1 – You Can Conduct Sprint Reviews by Email

RATING: FALSE

I am not even sure where to begin with this one. How is it possible that people feel that it is more effective to send an email vs. conduct a short focused meeting?

Here is what the Scrum Guide says about the Sprint Review:

• One of the elements of the Sprint Review is to “Inspect the increment”. In other words, the team and stakeholders take a look at the latest version of the product that has been built. How do you inspect the increment via email? I mean, you could send a link to the most current build but if people don’t have time to meet with you, why would you think they have time to follow a link and test drive the application?
• The Scrum Guide is clear that the Sprint Review “is an informal meeting, not a status meeting”. How is an email of the sprint review not a status report?
• The biggest problem with this approach is the lack of collaboration. The Scrum guide uses the words collaborate and collaboration 4 times in the description of the Sprint Review. For example, the Scrum Team and stakeholders collaborate on what was done and what should be done next. How can you do that via email? You can’t. Trying to create collaboration via email would be about as effective as newlyweds having their honeymoon via Zoom meeting.

Scrum Myth #2 – Scrum says that you must have Dedicated Teams

RATING: False

This was one that I heard during my Disciplined Agile (DA) training earlier this year. The instructor said that Scrum Practitioners won’t even talk to you about training or coaching if you don’t have dedicated teams.

I have long been a proponent of both dedicated teams and co-located teams, having seen firsthand the efficacy of having people in the same room working on the same product. Sadly, I was in the minority and this was prior to the 2020 pandemic. Globally, about 20% of teams were co-located with 80% using a remote or distributed team approach. I imagine that since the pandemic, almost no one is co-located. and that is likely to be the future.

However, the Scrum Guide doesn’t say anything about dedicated teams. In the words of one of my favorite Scrum experts, Craig Larman, “Scrum is Silent” on this issue.

As I noted in my review of the Disciplined Agile certifications, I thought that Disciplined Agile did a lot of unnecessary Scrum-bashing. At the same time, they are dogging Scrum about being out of date, using weird terms, and being too prescriptive, they also claim Scrum as their own. That is, they include Scrum within DA and say that if you are using Scrum, you are already using DA. Huh? It seems that DA wants to have their cake and eat it too.

Scrum Myth #3 – The role of Business Analyst is included in the Scrum Framework

RATING: Mostly False

This myth came from a comment on a blog that I wrote about the role of the Business Analyst in Scrum. The main point of my blog post was that in my experience, BAs like to operate outside the team, or do only BA work and that is inconsistent with the idea of having no specialists or sub-teams in Scrum.

That blog post has attracted the most comments and most of those comments are critical of what I wrote, claiming it to be too purist and not real-world enough.

The comment that triggered myth #3 was: “The Scrum Guide DOES mention BAs, and as part of the team…”

It got me scratching my head and wondering what I might have missed. I went back to the Scrum Guide and searched up business analyst.

Nothing.

I searched up business analysis and this came up:

“Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, “

Does this qualify as the Scrum Guide mentioning BAs? In addition to stating that there is no sub-teams, the Scrum Guide describes the Development Team as self-organizing and cross-functional.

“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”

Scrum Myth #4 – Planning Poker is Part of Scrum

RATING: FALSE

I include this one because it seems to be a point of contention for new teams. Not only planning poker, but estimating techniques in general. As the saying goes, the Scrum guide is silent on Planning Poker.

The Scrum Guide does mention the need for estimating and the importance of product backlog items being estimated. But it does not include planning poker.

It doesn’t include user stories either. Or epics.

No user stories in Scrum??? Epic! I’ve witnessed so many team debates over what is a user story and what is an epic to the point where a recent client asked for a template to write an epic. Wait, what? [See my related post: How to User Story]

In fact, there are numerous topics that cause debate and friction among teams first learning to use agile and Scrum. NONE OF THESE ARE IN THE SCRUM GUIDE!

• Fibonacci Numbers
• T-Shirt Sizing
• Velocity
• Daily Standup
• Project Managers
• Sprint 0 (similarly, no Design Sprint, Hardening Sprint, or Testing Sprint)
• Requirements Documents
• Fail Fast
• Jira
• Silver BulletsOther Scrum Myths?

Scrum Myth #5 – The Scrum Master is the Equivalent of the Project Manager

RATING: FALSE

False false false. Oh where do I start with this one. I guess first of all, each job requires different skill sets and the responsibilities are different.

Good project managers COULD become a Scrum Master if they worked at becoming servant leaders who fostered self-organization. Unfortunately, the task master type of PM who gets things done and makes sure everyone is doing their job is likely to fail as a Scrum Master. The best Scrum Masters have a zen like quality. They intervene infrequently and teams seem to do fine without them.

Read more about differences between Project Managers and Scrum Masters in this post: Project Managers Make Lousy Scrum Masters

 

This post included a few recent myths that I have learned of. I am sure that I missed a few. What are some of the myths that you have heard about Scrum?