I am listing out some commonly observed Scrum Myths, Mysteries, and Misconceptions from my experience.
- Scrum Teams are assigned to several projects or features. This results in context switching (i.e., multitasking), and the outcome is increased cycle time and delayed value delivery to business.
- The software is not released to market frequently, thereby missing the opportunity to gather customer feedback.
- When Scrum Teams say “Done,” they are not really “Done.” They need additional regression test cycles, or they need additional cycles to integrate their work with the work of other teams.
- There is more than one Product Owner for one product with no clear accountability.
- Proxy Product Owners are assigned to the Scrum Team with no empowerment to make business decisions, resulting in unnecessary delays.
- The role of the Scrum Master is undermined by assigning a part-time Scrum Master or team members taking turns to play the role of a Scrum Master in every Sprint.
- There is a certain myth that burn-down charts, burn-up charts, and cumulative-flow diagrams must be used by the Scrum Teams as metrics. The Scrum framework does not prescribe any of these metrics. Depending on the value these metrics drive, you can choose to use them or drop them altogether.
- It is a myth that success of the team can be measured by an increase in the team’s velocity. Velocity is neither good nor bad. It is just a metric that can be handy for planning. It is a metric to measure capacity, not productivity.
- There are Sprints called Sprint 0, Design Sprint, Architectural Sprint, Hardening Sprint, Stabilization Sprint, and Testing Sprint. The only true Sprint is a time-box of one month or less during which a “Done,” usable, and potentially releasable Product Increment is created.
- There are Sprints after Sprints just to build the overall architecture with no real business functionality at the end of each Sprint.
- Instead of recruiting someone with experience in working with Scrum, organizations recruit someone with no prior Scrum experience or send their in-house project managers to a two-day Scrum class, hoping they can play the role of an effective Scrum Master.
- ....
The above excerpt is from book "Scrum Insights For Practitioners: The Scrum Guide Companion"
What is your list of commonly observed Scrum Myths, Mysteries, and Misconceptions?