Prioritizing your backlog can be one of the more confusing exercises when your team first attempts to shift toward Scrum. It’s all too easy to wave your hands at it and say, "That’s the Product Owner’s problem, not mine" -- but no matter what your role is on the team, you’ll likely get involved at some point in time so it’s a process worth understanding.
When you properly feed a Product Backlog, it will actually prioritize itself. The problems most of us encounter come from not feeding it correctly. We stick task cards in without estimates. We adopt cards that fail to state business value. Or sometimes we attempt to dictate solutions with the cards we enter. So let’s start from the beginning and see if we can’t all get on the same page.
First, User Stories must state a goal instead of a solution. The reason that Scrum leads companies to hyperproductivity is because it removes the Command & Control model that artificially limits a team’s intelligence and speed to match the intelligence and speed of the Commander. A multiplicity of intelligent people pursuing a clear goal will always yield a quicker and superior result to having a central controller directing multiple workers. So job one is to state the problem, not the solution.
Next, you need to be sure that all work considered by your team has a clear and stated business value. Any work that doesn’t seek to generate value should be discarded as wasteful. Now some people will read that sentence and object that Engineering Initiatives and bug fixes are important, too. I agree. Just keep in mind that some work is an indirect value contribution -- like refactoring a module, for example. At first glance it looks like an expense but the ROI comes in the form of improved performance, increased stability or greater speed and accuracy when modifying that module for future feature support. So even infrastructure work and bug fixes carry Business Values, and they should be clearly stated just as with new feature requests.
So now you’ve got a collection of User Stories that state the problems instead of the solutions, and each has a statement of Business Value attached. You’re almost done. The last missing component is the statement of complexity from Engineering (a.k.a. "the Story Point Estimate"). This will likely lead to a long negotiation between the Product Owner and Engineering, during which they will mutually examine and modify the proposed User Story. Once it passes muster, the User Story can enter the Product Backlog and easily find its place in the queue.
Now there are a few sorting algorithms that you can choose to apply to your properly populated Backlog. You can choose to organize your backlog strictly by financial opportunities, but that may be short-sighted for your longer term goals for the company. You could organize your backlog to pursue a sequence of themes, but you may leave money or business opportunities on the table if you do this blindly. Or you could sort by desirability -- must-have, nice-to-have and optional. Personally, I think you should sort your backlog in each of the three ways and look for overlapping patterns to emerge.
No single method of sorting your backlog is likely to be right 100% of the time. This is why each team needs a dedicated Product Owner who can spend time analyzing the backlog to be sure that the team is heading in the best possible direction from each of the three perspectives. But before there is any hope of success, you must have a Business Value and a Complexity Statement on a card that conveys the problem, not the solution.
