The adoption of Scrum has increased rapidly and doubled in every industry. In 2020, the following graph shows the increase in Scrum usage.

Many people are adopting agile frameworks like Scrum but they don’t have the formal training or might not be very familiar with them. This article will dispel 5 myths about Scrum.

Scrum: Myth 1 Scrum should take care of this!

I once told managing managers about what transpired in the Sprint Retrospective during the last meeting with a fresh Scrum Team. They were moaning about not having anything to work on in the Product Backlog for the upcoming Sprint. All of the few items listed were complex and lacked specifics on how they could be executed. One manager inquired whether Scrum might fix this problem.

Many ask why Scrum Teams do not use a requirements document to plan their work. According to the Scrum Guide, they should use a Product Backlog instead.

The Product Backlog is the to-do list for the team. It includes a list of prioritized tasks for all stakeholders in order to improve quality and value of the product by maximizing these tasks.

If a new project starts with nothing in the queue, the team will collaborate about the most valuable thing to tackle next. They will do this at their first creative meeting, where they will create their first Product Backlog. In the first Sprint, the Product Owner will begin working on their whiteboard to fill it with ideas and tasks they want completed in future Sprints. During refinement meetings with Developers, items can be refined and sized according to need.

Slowing down in development is a risk for the development process when there are not enough Product Backlog items ready for the next Sprint. The developers end up spending lots of time talking to the Product Owner, who can’t always clearly explain what they want.

During the Sprint Retrospective, the team reviewed the issue and agreed to divide their projects into more digestible chunks. The Product Owner is responsible for the Product Backlog, however they have outsourced certain aspects of it to team business analysts. They were able to finish their backlog item size at a refinement meeting after splitting it down. Scrum’s built-in feedback loop enabled and encouraged them to discover and resolve the issue on their own.

Myth 2: Scrum is better with customization!

Scrum is not a set of instructions; it’s a collective intelligence. You should not modify the Scrum framework, but feel free to explore complementary practices and adjust Sprint duration for your environment.

Why? Scrum is a lean framework that only includes what is absolutely necessary. When teams tweak any aspect of the framework, they do not reap the full advantages.

Myth 3: There are no bosses in Scrum

People seem to not understand what a “manager” is in the Scrum framework. I’ve heard people say, “There’s no manager mentioned in the framework.” My response would be, “There’s also no CEO.”

People in the information technology department are often the people who receives reports from an organization’s Scrum Team. They are also the ones who can assist and remove issues that arise with the team. People who want to learn more about how to support an Agile team should take a Professional Agile Leadership course which provides insight into why Scrum is a good framework for Agile teams.

Myth 4: The greatest method to gauge team effectiveness is through velocity!

Many managers struggling to figure out how to support their teams turn to velocity to measure performance. They wonder how to measure success and hold team members accountable for delivery.

Velocity is a measure of how many tasks a Scrum Team can do in a given amount of time. However, it is not always correct in determining the importance of the team’s performance. Why? Because velocity discusses how much work is being done but ignores the quality or importance of what is being produced. It is solely for planning purposes.

Scrum teams use a point system for each product backlog item to help them estimate the time that it will take to complete. Velocity is their points at the end of their sprint, it helps with planning future work and has no relation to success.

Myth 5: Component teams can function anywhere.

Some new Scrum Teams combine different job roles into one team despite traditional managerial structures in the organization. Scrum has Java developers and content writers who are still separate teams but work closely with each other because of their cross-functional expertise.

Teams should have a shared workflow and inventory before forming Scrum Teams to deliver value. Otherwise, the end product will fall behind and tech work will slow down because of bottlenecks. For example, if work is considered of high importance for one team, it might be considered irrelevant for another team and vice versa.

Wrap up

There is a lot of misconceptions about the Scrum framework, especially in agile environments. Certain myths have grown from agile adoption, which has not been handled with formal training.

Scrum is not going to solve all your problems, but will make them visible that the team can hash out. Managers need to understand that managing work in a complex environment is different than managing work in a traditional environment. Unique skills and metrics are required to measure productivity. You should know what product you are trying to deliver before forming an agile team or ask yourself if you have relevant skills and complexity metrics.

If you are new to Scrum, I recommend the Applying Professional Scrum course which offers a comprehensive overview of the accountabilities, events, and artifacts needed to form a high-performing Scrum team. If you will be fulfilling the Scrum Master accountability, I recommend the Professional Scrum Master course. If you are interested in learning about how to scale multiple Scrum teams working together on a single product, I recommend the Scaled Professional Scrum course which presents the Nexus framework.