Many videos about Scrum actually mis-represent the Scrum method. In this BERTEIG video series, Mishkin Berteig, Certified Scrum Trainer and Scrum expert, breaks down some of the biggest myths and shows what Scrum really is and what it isn’t.

Myth 1: The ScrumMaster is a Project Manager

Many videos about Scrum mis-represent the ScrumMaster role. Mishkin Berteig, Certified Scrum Trainer and Scrum expert explains this myth and why it is incorrect and why a ScrumMaster should never be assigning tasks. What is a ScrumMaster really?

Myth 2: The Retrospective is Public

Many organizations ask their Scrum teams to publish and share retrospective results on a wiki or content management system. Or Scrum teams have managers and stakeholders attending the retrospective. This causes huge disfunction in a Scrum Team. The retrospective should be private.

Myth 3: Sprint Zero is a Part of Scrum

In this short video, Certified Scrum Trainer, Mishkin Berteig, blows away another of the myths of Scrum: that there is such a thing as a Sprint Zero! This is one of the earliest myths of Scrum and it can cause huge problems.

Myth 4: Scrum is for IT Projects

Scrum is not just for IT projects. In fact, Scrum doesn’t work perfectly on IT projects. What is Scrum ideally suited for? Find out why Scrum isn’t so good for IT projects and what it is good for.

Myth 5: Excessive Preparation

Many organizations continue to apply waterfall thinking to Scrum work by doing big up front planning and design… excessive preparation. This is not appropriate with Scrum. Instead, we dive into the work… find out how and why we avoid excessive preparation.

 Myth 6: Stretch Goals are Good

Stretch goals are bad news normally. In Scrum, stretch goals are a disaster! Stretch goals destroy trust which is fundamental for the effective operation of a team. Find out why stretch goals are so bad for a Scrum Team.

Myth 7: Developers Determine Order of Product Backlog Items

The technical members of a Scrum Team are responsible for implementing Product Backlog Items every Sprint… shouldn’t they decide what the best order of implementation is? In Scrum, this is not the job of the team… it’s the job of the Product Owner.

Myth 8: Distributed Team

Distributed Scrum teams can work, but they can never be great. All too often, an organization creates a sub-optimal work environment. As a process, Scrum can be used by a distributed team… but a distributed team is ignoring the message of Scrum used as a framework: “get into a room together!”

Myth 9: Changing Team Membership for Efficiency

Traditional “resource management” focuses on matching individual people’s skills and availability to work that needs doing. In large organizations, this often means a focus on maximizing utilization by moving people around depending on this matching process. Scrum is different and asks us to focus on teams as resources instead of focusing on individuals. This helps us achieve important business and work satisfaction results.

Myth 10: Non-Scrum Roles

Many organizations continue to maintain traditional IT / technology roles when they switch to using the Scrum process… but this isn’t Scrum! Scrum only allows three roles. Why is it wrong to have a tester, a business analyst and database admin on a Scrum Team? Find out the advantages of re-defining all the roles in your organization.

Myth 11: QA After Sprint

Many Scrum Teams consist of just coders. The Scrum Team then passes their work along to a QA department for functional and integration testing. This is wrong: Scrum requires “done” software be produced every Sprint.

Myth 12: Shared ScrumMaster

Don’t share your ScrumMaster across multiple teams! This is false economy and false efficiency, and it isn’t allowed by Scrum.

Myth 13: Technical Items in the Product Backlog

The product backlog is for business problems, user needs and wants, features and functionality. The product backlog should not contain technical items. Instead, the Scrum Team takes care of technical issues, problems, solutions and techniques. This is fundamental to the division of responsibilities in Scrum.