Jim Coplien and Brent Reid describe different but related reasons why the backlog needs to be ordered in order for a sprint to receive items to work on. The product owner will need to ensure that backlog items have priorities – but those priorities don’t provide enough information to work out the order that items should be presented for development.
Jim’s article gives a great example. Let’s say that we’re currently in November and there’s a medium-priority item in the backlog that will result in a Santa Claus image being displayed on a web site. There may be higher-priority items in the backlog, but if the Santa item isn’t developed before December then the priority of the item (and it’s value to the business) will fall dramatically. In fact, if we display a Santa figure on the site in February then that would probably have a negative value. So the decision that the product owner needs to make in this case, after discussion with other stakeholders, is whether to present the Santa item for development before higher priority items – or whether to drop it until next year at least.
And there are other situations where an item might be presented out of priority order, such as small lower priority items that can be fitted in within a sprint alongside larger high-priority items. And even within one band of priorities (“We have ten items that are top priority!”) the product owner needs to decide which is the most appropriate order of development.