1

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.
2
  • How on Earth can "dependency between features" not be Nr. 1? Feb 1, 2014 at 9:57
  • These are not necessarily sorted by importance.
    – Eugene
    Feb 1, 2014 at 11:35

3 Answers 3

4

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.

3

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.

6
  • But why develop something with a high risk earlier? Isn't it better to develop all the low hanging fruits first so in case application needs to be released it will have enough value?
    – Eugene
    Feb 4, 2014 at 14:47
  • That's why value is also part of the equation. You don't want low-value high-risk items first. If you have high-value or mid-value items with risk, you should do those before high-value low-risk, because you don't have risk in doing those later. Ask your devs: if you have 2 days left in your timeline, do you want to start on some easy stuff, or the riskiest stuff in the project? That's why you raise priority on riskier items: project risk mitigation. With that said, if you can deliver minimum shippable without a risky item, that probably indicates a low business value anyways.
    – Jay S
    Feb 4, 2014 at 16:48
  • I understand. And did you fix all bugs in the risky items as well? Sometimes it makes sense not to fix all bugs because if there is a risk that the user won't like the item, the bug fixing would be a waste. On the other hand this goes against Scrum's emphasis on potentially shippable product increments.
    – Eugene
    Feb 4, 2014 at 16:55
  • For risky items we attempt to chunk into more palatable pieces that can be delivered iteratively, and then resolve 'showstopper' bugs that would prevent delivery. Essentially, the story isn't "Done". Other bugs that are lower priority go to the backlog to be prioritized alongside other work.
    – Jay S
    Feb 4, 2014 at 17:30
  • I see, but this goes against the shippable product increment paradigm. Are you okay with that? It means you probably have a several sprints stabilization phase and such.
    – Eugene
    Feb 4, 2014 at 17:36
1

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.

1
  • 2
    In Scrum, there is no picking and choosing for the development team. The Product Owner determines the order and the development team pulls as many features as they can handle from the top of the pile. Feb 1, 2014 at 17:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.