Does it matter in what order a Scrum Team executes their Sprint Backlog?
Over the last few years I’ve had folks from various roles on agile teams ask me if I thought it was important if the stories in a sprint backlog were executed on in their rank order of importance, because “after all, the team made the commitment and they should be delivering the entire backlog during the Sprint.” Recently I heard the previous quote from a CSM so I thought I would set the record straight based on my experience with Scrum software development.
In the application of Scrum I’ve seen over the years, I would say that it actually is important that teams respect the order of ranking of stories in the backlog when executing. It is the tasks and tests of a story within the backlog they can work on in the order they want. The reason for respecting the rank is that otherwise, too often you get teams that spread out over all the stories at once. The sprint team’s burndown chart will show the team burning through all their hours, but their cumulative flow graphs show little to no value being earned. Many times this is a sign that the team is doing mini-waterfall within an iteration. Try applying WIP limits across the the team’s value flow and very soon you’ll see the importance of executing in rank order when you’re trying to maximize the value out of flow.
In my real world experience working with clients, the ideal of an uninterrupted sprint for companies that have substantial technical debt in the wild is not the norm, it is the exception and these organizations require approaches that can more gracefully handle escalations. I know that this is against “Scrum religion” but ideals are more easy to talk about than to practice, and the focus is usually to aspire to the preached doctrine. That is why we have retrospectives 🙂