I recently watched a talk by a self-appointed agile "expert" who tried to explain the key elements of Scrum. There were lots of minor and major mistakes in his presentation, but the sentence that struck me most was: "User stories are what we call requirements in agile." The sad thing is not that much that this guy said was completely wrong, but that his view is quite common.
Another "Scrum" team I was visiting recently showed me its task board. On the left, the group had "prioritized" their stories by assigning them to three categories. Their choice was pretty representative: they had eight cards with priority one, three cards with priority two, and not a single card with priority three. "Yes, we have heard about this theory," they told me when I asked whether they had heard about full prioritization. "But in practice we found no value in it." They could not really answer my question why they thought that prioritizing their eight number-one tasks by rolling dice — which is, in fact, what their priorities lead to — produces more value.
These are just two of the patterns I see more and more when visiting teams that have started with agile just by reading a book or attending a two-day course. The problem with these misconceptions on how to handle the backlog is that managing the backlog of an agile project actually means managing the project. If the backlog is managed well, your project has good chances to lead to customer satisfaction and success. If the backlog is managed badly, the project is doomed — it will probably produce the wrong system, no matter how skilled the programmers are.
What Makes a Good Backlog?
In short, a backlog helps the team to develop the right software in tiny baby steps. The goal is to enable steady accrual of business value during the iteration. Mike Cohn has proposed several rules on how user stories and backlogs should look, such as the INVEST rules for user stories (independent, negotiable, valuable, estimable, small, testable) or the DEEP rule (detailed appropriately, estimated, emergent, and prioritized) for the product backlog. However, from a management perspective, I have found a very simple test with two indicators that shows you whether a product backlog works:
The burndown chart (which indicates the user stories done; i.e., production ready) decreases almost linearly, almost like a skiing slope. If, in contrast, your burndown looks like a waterfall, your stories are probably too large and you probably run each sprint as a tiny waterfall with all the risks.
A domain expert understands the user stories presented during the product review without too much explanation — and complains that this is only a small fraction of the job: "This is fine, but there's a lot of functionality missing."
Do this test with your teams. It's a pretty safe bet that at least half of them fail this test. Understanding that the "user" in "user stories" really means taking a user's perspective takes time. And learning how to chuck user stories takes time, too. Tools such as Jeff Patton's "Story Maps" help, as well as Richard Lawrence's patterns for splitting user stories. But applying all this is not simple — and a good coach helps you avoid the multitude of traps on your way to get there.