For a relatively simple development framework, Scrum is often misunderstood – even by experienced IT leaders. As a certified agile practitioner and project management professional with over 25 years of experience delivering software development and IT products and services, I felt it was high time to debunk some misconceptions about Scrum. Here are seven common ones.
Myth #1: Scrum teams should be co-located
Some Agilists tout many advantages to co-locating teams, including osmotic communication (overhearing conversations), information radiators, and even non-verbal observations like “EQ.”
But The Scrum Guide makes no mention of co-location. It is, however, a concept promoted by other Agile practices, such as Crystal and Pair Programming. Scrum has proven to be highly effective for virtual teams that use virtual tools to implement Scrum ceremonies and artifacts.
[ Read also: 3 DevOps, agile, and scrum myths, debunked. ]
Myth #2: Product backlogs must have user stories
Scrum requires only that backlog items have an estimate, a business value, and an order or ranking. Scrum does not require backlog items to be written in a user-story format. The user-story format is the result of an evolutionary collaboration between other Agilists who successfully applied a natural language approach to the art of writing requirements. The approach works well within the constructs of Scrum, so it has been widely adopted by many Scrum teams.
[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]
Myth #3: Burndown charts are an artifact of Scrum
Ken Schwaber is often credited with the invention of the burndown chart, and its concept was borne from the Scrum community. But the burndown chart is not an artifact in the Scrum Guide. The Scrum Guide states that, although useful, these projective tools “do not replace the importance of empiricism.”
In other words, make forward-looking decisions based only on what you know from the past. Even burndown charts can’t predict what will get done in time. There’s always the risk of the unknown.
Myth #4: SAFe and Scrum are the same thing
Although the Scrum team is a fundamental element of the Scaled Agile Framework (SAFe), Scrum and SAFe are two different things.
Scrum was conceived and had been employed for roughly 20 years before the introduction of SAFe in 2011. In the early days of Agile, the Scrum framework set the precedent for small, atomic teams on their journey to agility. But large interdependent organizations often struggled to institutionalize the Scrum framework because of its independence from other functions within the organization. Dean Leffingwell introduced the world to SAFe as a scaled-up approach to coordinating the work produced by many Scrum teams and the various functions within the typical large organization.
Let's dig into three more myths:
