3

What are different aspects of a PBIs (Product Backlog Items), or generally speaking features, would you take into consideration for prioritizing the backlog? risk, ROI, time to market, cost of delay, at PO's discretion, etc.

Would you consider a combination or even a weighted combination of those to prioritize the backlog?

How often is necessary to revisit the prioritization? At every sprint? on a daily basis? or at PO's discretion?

  • As currently written, this question is too broad. Please improve the question by providing some context about your specific situation, what you've already tried, and why that's not working for you. – Todd A. Jacobs May 25 '17 at 23:55
  • Highest value, highest risk, lowest cost – Sahan De Silva May 26 '17 at 5:47
3

Let me tackle the two parts of your question slightly separately.

How To Prioritize

The Scrum Guide says that "The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." At the end of the day, the Product Owner has final say over which of the criteria you listed is the best way to prioritize the backlog. However, the whole team as well as stakeholders can be involved in helping the Product Owner make judgement on the complexity, ROI, risk, etc., of a PBI. In other words, engineers, designers, business analysts, business stakeholders, QA Analysts, and others can provide valuable input to help the PO make a call on how to prioritize.

Generally, I've found a few methods that help Product Owners to come to grips with prioritization:

  • MoSCoW Prioritization -- categorize high-level features/epics by Must Have, Should Have, Could Have, and Won't Have for an upcoming release. Working with the development team to understand timeline and risk, the PO can determine what features must make it into the next release of the product, and then two separate levels of "Nice-to-Haves." Won't Have also helps specifically rule out less important features. I STRONGLY suggest using real corkboards with sticky notes or index cards for this exercise.
  • User Story Mapping -- Explained pretty well here, if you have specific user stories written out you can prioritize them by functionality, then draw your MMF/MVP line based on what features are absolutely necessary and which aren't. This is pretty easy to do on a whiteboard or large piece of paper with sticky notes.
  • The "Hundred-Dollar" Method -- The Product Owner and key stakeholders get 100 "Dollars" or "Points" to allocate to the various user stories or features on a corkboard or whiteboard. Participants can put as many of their points toward any specific feature they want. (Engineers may put a lot of points toward refactoring a legacy product, while marketing may put a lot toward a flashy new feature. The CEO may put all of his or her points toward what he or she thinks will have the biggest ROI.) The PO can then use this information to help them prioritize their backlog.

When To Prioritize

For high-level feature prioritization, I recommend having a Release Planning session minimally once per quarter. If multiple releases are planned for a quarter, each one should have its own Release Planning session. This is where a PO can use MoSCoW prioritization or other methods to help determine what will be in an upcoming release at a high level.

During development, the priority of the Product Backlog can be changed at any time by the Product Owner, taking into account the necessity of grooming/refining items before they're put into a Sprint. In other words, teams should never commit to items that they don't consider fully groomed, even if they are at the top of the backlog.

At a minimum, teams should review the near-term prioritization of items with the Product Owner at every Sprint Review and Grooming meeting to ensure that they are refining the right items for the next Sprint and working on the current highest-priority features.

I hope this helps -- feel free to let me know if there's anything I didn't cover here!

  • I used this for Story Mapping winnipegagilist.blogspot.ca/2012/03/… Thanks for the link to ScrumAlliance. – sheidaei May 26 '17 at 12:56
  • The methods you mentioned are ways of prioritizing the backlog, they are not talking about the factors being considered in prioritizing. What are the factors being considered in prioritizing? – sheidaei May 26 '17 at 12:58
  • 1
    I think you've accurately classified the appropriate factors in your question. I don't think anyone can give you a formula to say "It's X% ROI, Y% Customer Asks, and Z% Risk." Part of a PO's job is to figure out what works best for their organization and their product when it comes to priority, and it's an iterative process. Inspection of how your last release went should lead to adaptation of your prioritization process. – JDRoger May 26 '17 at 13:17
  • 1
    Just to tack on a little bit here -- at my firm we've worked on projects from medical devices to consumer mobile apps to enterprise-level risk management systems. I've never had two product owners who have prioritized the same way. – JDRoger May 26 '17 at 13:36
0

I my opinion, it depends on what is the objective of your product. According the Scrum Guide regarding Product Backlog responsibilities:

Ordering the items in the Product Backlog to best achieve goals and missions;

I think that any decision must be made together with your client, what is the product mission. In my company, usually I use ROI first to rank and Risk second, to solve any tie.

  • By making a decision with the client, I think you mean collaborating with the client on the decisions and get their feedback. The client, might not know the process you are going through, and might be confused, right? For example, a client asks for a feature and the PO works with the team to break it down into smaller PBIs and deliver them one by one. I agree with you on getting the Client's input 100%. – sheidaei May 26 '17 at 12:42
  • Well, the client maybe not know is the software development process, but he must know what needs most. In you example, all the stories related to that epic should get a higher priority, do you agree? – Vander Lauriano da Silva May 26 '17 at 17:34
-1

This Medium article "How to prioritize Feature Requests and Product Improvements" sheds some light on the backlog prioritizing process beyond operational formulas and weights. It helps navigating through the different stages of a product with different needs in the backlog (create-grow-mature)

https://link.medium.com/Ybn8KR7GmR

Beyond this, considering ROI, TTM or anything other risk/benefit/uncertainty metric is rather subject to personal preference and requirements of your organization. For example: when you must meet a fixed shipment schedule with monthly releases your ability to finish a certain backlog or hide unfinished enhancements is crucial. In an environment driven by short term profit you rather want to prioritize by ROI.

  • Link-only answers aren't acceptable on Stack Exchange. Please quote the relevant material, and explain how this addresses the original question. – Todd A. Jacobs Oct 28 '18 at 0:59

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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