Criteria for prioritizing product backlog

Question

My list of the most important criteria is below. What do you think?

1. The value to the user - naturally features that are more important to the user must come first
2. Implementation time - the faster it is to implement a feature, the higher it should be on the list
3. Dependency between features - obviously you can't make a "roof" feature without developing the "walls" feature first.
4. Risk reduction - If a certain feature is very important for the project but we are not sure if we can actually develop it (because of either technological limitations or because we don't know how users will react to it), it climbs up on the list.

Answer 1

In Scrum, the ordering of items in the Product Backlog is the sole province of the Product Owner.

There are many different ways to achieve this. From the simple:

Use the business value and estimate that should be attached to each Product Backlog item. Calculate a simple Return on Investment (RoI) number by dividing business value by estimate. Higher value RoI is ordered higher in the Product Backlog.

To the more complex, where Product Owners create their own, bespoke algorithms.

There are other factors that a Product Owner might consider as well such as risk (do high risk items first) or technical advice from the Development Team.

But the fact remains that only the Product Owner establishes the order of items in the Product Backlog.

One other quick note: When writing Product Backlog items, a guiding principle is to keep the items independent. It's not always possible, but Scrum Teams strive hard to achieve this. Therefore, the notion of using dependencies to decide ordering is rarely needed or used.

Answer 2

In my experience, when myself or the Product Owner have needed to take into account the full complexity of the stories, we have used the following:

1. Business Priority
2. Development Effort
3. Development Risk
4. Test Effort

In our situation, we use development risk to identify items that should be done earlier to allow for more revision cycles and feedback. We include test effort to make sure that we don't try to do a bunch of things that are easier to build, but very difficult to test. Both Efforts are used to make cases to clients that an item should come earlier in the backlog, as it will take more time to implement.

When trying to maintain something close to a schedule, reducing risk to slipping on your delivery date is important to the business as well, not just the value of the items.

That being said, when we have ties, or things seem close, the business value needs to be weighted stronger. We can't just deliver a bunch of low value stories that are difficult to build, test, and have a high risk. For this reason, business value gets a stronger weight in our calculations.

Answer 3

You are mixing two things here : priority for business and technical priority. And both things are handled by different people. Business priority should be chosen by customer/product owner. This is how the whole backlog should be ordered. No technical things are taken into account by this list. Developers then pick from this list based on technical priority. The key point is that they don't have to pick top 10 items, but they can cherry-pick items they know they can implement in the sprint, but that still have high priority.

The problem of mixing both into single list is that the business value gets blurred. For example, some story might have huge business value, but might take long to implement. In your case, it would drop down even though it is really important thanks to mixing the implementation time into it. Similar if this story depends on other stories, that might have lower priority. If developers don't pick it outright, the fact that it is still on top of list reminds them that they should focus on implementing it in next iterations. On the other side, they might pick low-priority story simply because it is short and no other story would fit into remainder of the iteration.