What Scrum isn’t:

Sources used:

• The 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland.
• Things Ken Schwaber Intentionally Omits From Scrum by Michael James.
• Dark Scrum by Ronald E. Jeffries.

Scrum isn’t going to improve performance

• Not immediately at least.
• Scrum is not designed to be the most efficient way of working.
• It is designed to be able to make changes, before a lot of wasted work has been done.
• So it is better at changing focus, with the added cost of maybe having less throughput.
• A lot of businesses misinterprets Scrum as a way to save development costs.

Scrum isn’t daily status meetings

• It was never part of Scrum that people daily should list what they have been doing.
• The original “daily Scrum” was to discuss progress towards the sprint goals, not specifically a status. Many things could be done, and a status is one of them.

Scrum does not talk about “Velocity”

• Maybe it originated from extreme programming, but it is not from Scrum.

Scrum does not contain story-points or Fibonacci numbers.

• Scrum does not proscribe any particular method to estimate. Whatever works for the team.
• Some suggests that exponential estimates work better than absolute estimates.
• Using more than very few choices gives the illusion of precision.
• Also it is up to the team to decide what to try and get done in a sprint, and thus it does not really require an estimate.
• Some points out that estimation has no value at all, and we need to stop doing it.

PO cannot assign work to a sprint

• The developers discusses with the PO what needs to be done, and based on that chooses what is brought into the sprint.
• If developers are told what to do, and when to do it, they burn out and stop caring about the product and the business.
• The point of agile and Scrum is to “be able to maintain a constant pace indefinitely”.

The backlog should not contain tasks

• Scrum separates the what from the how.
• Therefore the backlog should only ever contain what. Or Product backlog items (PBI’s)
• A task is created for a sprint, during sprint-planning by the developers.

Scrum does not contain burn-down charts.

• While burn-down charts can be a useful tool, it is not part of Scrum.
• Burn-down charts can have the downside of focusing to much on estimates, and short-term optimisations, rather than the longer goals of the business.

Scrum masters are not for status reporting

• If they were, they would be called project managers.
• “Working software is the primary measure of progress”
• So at the demo everyone can see the progress, and status reporting becomes irrelevant.