Worrying interpretations of Scrum

At an Agile event I attended recently the speaker surveyed the audience about the 9 elements that form Scrum. My suspicion was immediately raised with mentioning of “9”. It only got worse when the speaker came up with:

Definition of Scrum (9)

It got me wondering how many misconceptions of Scrum can be expressed in no more than two minutes:

Definition of Scrum (9?)

I was hoping that by now (2016), and certainly given the availability of the Scrum Guide (since 2010), the basic understanding of Scrum was better.

What worries me the most however is not the formality of the wrong and missing elements, but how this reflects an ineffective use of the Scrum framework, a limitation to how Scrum supports teams in creating great software products:

  • Accountability over the self-organized creation of Increments belongs to the Development Team as a whole. Synergy is key, not individualism.
  • Transparency is optimized when Product Backlog holds all types of work and requirements for the product. The format and syntax of Product Backlog items is open for the teams to decide over. User Stories are certainly not mandatory.
  • Burn-down charts were removed as mandatory from Scrum some years ago. It was replaced by the expectation that progress, regardless the format, is visualised on Product Backlog and Sprint Backlog.
  • If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a releasable Increment in a Sprint. It is the basis of empiricism, of business agility. Imagine my surprise that this was not even mentioned, THE core purpose of Scrum.
  • Scrum has no prescription that the Daily Scrum needs to happen standing up. Scrum’s interest is making sure that the team’s progress toward the Sprint Goal is inspected on a daily base, in order to allow the team to adapt.
  • The Sprint Review is a collaborative event at which the Scrum Team and the stakeholders work together, and identify what is most important to work on next. Adding input from the stakeholders to the inspected, current state of the software (via the Increment), improves that decision. It is so much richer than a demo.
  • All events in Scrum are contained within a Sprint. Sprints take no more than 30 days, and often less. Not mentioning the Sprint as such (container) event might allow to overlook that aspect.

Definition of Scrum (11)