Scrum: folktales, facts, alternate- facts, and other nonsense !!

Scrum, today, has become the most popular framework. Naturally, the folklore around it also has grown over the course of time.  Scrum was first published in 1995, and Scrum Alliance officially founded in 2001.  During those times, the main source of Scrum was the creators of the framework.  Naturally, word of mouth has its limitations on scalability. The first official Scrum Guide was published in 2010. And subsequent editions clarified many of the practices, simplified the rules and eliminated confusion.  Unfortunately, today, many people try to capitalize on the popularity of Scrum and have created their own versions on Scrum (alternate facts !!).  I recommend you honor those who created it and stick with Scrum as described by The Scrum Guide.

So here are a dozen common misconceptions about Scrum.

1. Folklore – Scrum and Agile are synonyms –  Fact – Scrum is a framework under the Agile umbrella.  The other methods, methodologies, and frameworks under the Agile umbrella are eXtreme Programming (XP), DSDM, Crystal, Adaptive Software Development (ASD) and Feature Driven Development (FDD). 
2. Folklore – Product Backlog and requirements are the same –  Fact – Product Backlog is a much more encompassing term than requirements. You can have anything in the Product Backlog as long as the Product Owner sees value in it. These can include features that need to be built, customer discovery experiments, road maps, etc. 
3. Folklore – Product Owner is a new label for Business Analyst –  Fact – Product Owner is a role with a lot more authority.  They are responsible for the return on investment of the “product”. 
4. Folklore – Scrum Master is a new label for Project Manager –  Fact – Scrum Masters have very little (yes, absolutely very little)  to do with traditional project management responsibilities.  Most of the project management responsibilities are taken over by the Dev. Team. And some of the project management responsibilities are no longer needed (e.g. risk management plan) as they are incorporated into the Scrum framework
5. Folklore –  Product Backlog Items (PBIs) should be written as User Stories  –  Fact – User stories are one way to write Product Backlog, they are not the only way. Though, it is common to write PBIs  as User Stories (and I encourage it), PBIs need not always be user stories. Tip – Please stop writing regression “stories”, testing “stories” and other nonsense stories (sorry for being harsh !!).
6. Folklore – Sprint Burndown charts are part of Scrum. The Development team should use them to track their progress –  Fact – Sprint Burndown charts used to be part of Scrum, but it is not the only possible way to track the Dev. Team’s progress. So they were removed in the later versions of Scrum. Today, Sprint – Burndown charts are NOT part of Scrum, though it common for Dev. Teams to use it (and they can use other techniques as well e.g. Sprint Burnup chart). 
7. Folklore – You can only release PBIs once a Sprint –  Fact – Sprints are “planning” cadence, not “release” cadence. You plan release the PBIs to production multiple times during the Sprint, and nothing stops you from shipping the features to production multiple times a day. 
8. Folklore – Relative estimation techniques (e.g. Planning Poker)  are part of Scrum –  Fact – They are not. Scrum does not recommend any one way, shape or form of estimation. You can continue estimating using “person-days” and still you will not break the rules of Scrum. The ubiquitous  popularity of  these “Planning Poker” cards stem from the fact that tool vendors, consultants, and trainers gave away free decks of “Planning Poker” cards (along with their branding).  Who does not like free stuff? 
9. Folklore – The Dev. Team has to answer three questions during Daily Scrum –  Fact – The Daily Scrum is a daily “inspect and adapt” meeting towards helping the Dev. Team achieving the Sprint Goal. The 2017 version of the Scrum Guide suggests that the “three questions” as an example that might be used. 
10. Folklore – Product Owner is not required for retrospective meetings  –  Fact – Product Owner is mandatory for retrospective meetings as they part of the Scrum Team. If the PO does not want to participate in the retrospective / the Dev. Team does not want the PO to participate in the retrospective, the underlying dysfunction should be addressed.
11. Folklore – Scrum Master must facilitate the Daily Scrum –  Fact – Scrum Masters need not (and IMHO, should not) facilitate the Daily Scrum. The Scrum Guide says,”…Development Team is responsible for conducting the Daily Scrum”, “The Scrum Master ensures that the Development Team has the meeting” and “The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.” 
12. Folklore – Scrum Master must facilitate retrospectives –  Fact – Scrum Master may facilitate it  (Scrum Guide – Scrum Master Service to the Development Team “Facilitating Scrum events as requested or needed”) usually, but the Scrum Team can also have an external facilitator (e.g. Scrum Master from another Scrum Team) facilitate the event. At minimum , “The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process” 

So does it matter if it is a Folklore or a fact? I think it does. Why? Because (a) it promotes a simple and common understanding for people in the organization (b) You know what practices are mandatory and what practices are optional.

Based on your experience, what do you think are the other folklore that exists today?