Backlogs aren’t just a collection of requirements, they’re also a statement of scope. The "must haves" in a backlog are used to represent 100% of the current committed scope. Although this will naturally change over time the understanding of scope means that we can measure progress by the amount of the backlog that has been completed to a given Definition of Done. As a result, if we measure completion over time, then we can extrapolate forward to indicate when the must-haves will be complete.
The “would like to haves” become a wish list for the currently committed scope. This means that Backlogs are theoretically endless making multi Release backlogs a little more difficult to work with. Instead of over complicated prioritization schemes we recommend that items in a backlog are first tagged by Release. The immediate Release is the only one that will be further worked with, everything else can be filtered away until we’re almost done with the current Release.
Within the current Release we recommend ordering Backlog items, with Customer involvement and agreement, in terms of a simple prioritization scheme. Either High, Medium, Low or forced-ranking are acceptable. We recommend considering the bottom “chunk” as “on the bubble” meaning that the lowest n-items (as agreed between teams and their Product Customer) are at risk. This is an honest reflection of the realities of software development.