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
Myth 6: Stretch Goals are Good
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.