A backlog is basically the list of stories we want to build. Organize features—stories—in different ways. You can organize them by themes, by user type, by purpose, or any other way that makes sense to you. Essentially you’re aggregating features to make a release. This is called the minimum marketable feature set (MMF) and it tells you what you absolutely need in this release in order for your product to be viable and usable.
If you know what your MMFs are, then you can add a few nonessential features to a release so if development finishes early there’s something to work on. But if you run out of time, then you know what your drop dead is, and what capabilities you must include in order for the user to derive value from it.
Talk about ordering the backlog instead of prioritizing the backlog. The Product Owner is the one responsible for saying what is to be built next, and that’s the next most important feature to build. But sometimes what’s “most important” isn’t as obvious as anyone would like it to be. Sometimes it’s more efficient to build the second most important feature first because it’ll also include capabilities that the more important feature will need, and it’s a simpler path there.
Keep the ordering process flexible. That way, the team agrees on your MMFs and the order of the backlog items for the next few iterations, but then if someone gets a better idea, that idea can be exploited.
Here’s the rule of thumb I try to adhere to: if a feature is in iteration I want to keep on task with that, but if this new idea is something that could be done in the next iteration or an upcoming iteration, then I do want to incorporate it—and there’s no reason I can’t. I just want to be careful not to stop developers mid-iteration, invalidating everything they were just doing. But then adding something to the order after that is why teams have the backlog in the first place; it’s why we build in iterations, so that we can introduce something new when we realize it’s better.