top of page

Prioritization and the Product Backlog

The Product Backlog

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. However, the key to managing the Product Backlog is a combination of communication, transparency and trust.

The Product Owner

The Product Owner is accountable for the stories that are written and placed in the backlog. Business Analysts are often thrust into the Product Owner role. However, Business Analysts don't always have the the authority to make the final decision about priority.

Prioritization Forum

In the case that you are performing the role of Product Owner and don't have the true authority, it is absolutely necessary that you establish a prioritization forum.

  1. Identify the stakeholders who will have the responsibility and authority to make decisions about the work

  2. Communicate how priorities are determined and what part each person plays in the decision process

  3. Determine the forum for how changes will be managed

  4. Come up with a cool name for the meeting that incorporates the word "Team"

In the past, I have worked with internal teams such as Product Management, Marketing, Compliance, and Risks teams to develop new financial products. We met monthly to review the backlog with these teams. In addition, we had a quarterly meeting with the field to communicate priorities, collect feedback and make adjustments as needed. We called this group the Prioritization and Authorization Team or PAT Meeting.


  • Benefit: the advantage that accrues to stakeholders as a result of requirement implementation, as measured against the goals and objectives for the change. The benefit provided can refer to a specific functionality, desired quality, or strategic goal or business objective.

  • Penalty: the consequences that result from not implementing a given requirement. This includes prioritizing requirements in order to meet regulatory or policy demands imposed on the organization, which may take precedence over other stakeholder interests. "What happens if we don't do it?"

  • Cost: the effort and resources needed to implement the requirement.

  • Risk: the chance that the requirement cannot deliver the potential value, or cannot be met at all. The Product Owner should consult with the Project Manager to discuss Risks so that the proper Risk response is in place.

  • Dependencies: relationships between requirements where one requirement cannot be fulfilled unless the other requirement is fulfilled.

  • Time Sensitivity: This includes a combination of other scenarios such as regulatory, risk response, and costs benefit. Other items to consider are speed-to-market or seasonal activities.

  • Stability: the likelihood that the requirement will change, either because it requires further analysis or because stakeholders have not reached consensus. I've found it is helpful to give stakeholders an opportunity to complete the requirements by a specified date. Make sure to include lead time for analysis and feedback from the technical teams.

  • Regulatory or Policy Compliance: requirements that must be implemented in order to meet regulatory or policy demands imposed on the organization, which may take precedence over other stakeholder interests.

As there are multiple stakeholders, each group will have a different perspective on the previous list. Marketing wants it now to stay ahead of competition. Compliance doesn't want to move forward due to risk exposure based on verbiage in the contract. Conflict resolution and negotiation are required to keep the discussion productive.


Some topics are more controversial than others. Spend time with your stakeholders prior to

the meeting to understand objections. Be prepared to address those objections. #nbdleaves


Remember the Pareto Principle?

80% of the results will come from 20% of the work. These are the features or functionality that will achieve most of the results. So, keep this in mind when prioritizing the work.

Apply MoSCoW

From a broader perspective of organizing the work, use MoSCoW to rank your backlog. As a Product Owner you should be grooming your stories prior to meeting with the team and be ready to discuss stories with the team. Assuming you have 100 backlog items, rank as follows.


The more transparent you are about priority and the timing of the changes,

you'll receive less requests for changes. #nbdleaves

  • Must Have [Rank 01 - 025] This is likely 20% of the work and should be at the top of your backlog, high penalty or regulatory items are here as well

  • Should Have [Rank 26 - 050] Think of this as work that gets edged out due to capacity or time constraints; set expectations that this work may be pushed to a future release

  • Could Have [Rank 50 - 075] These features are generally dependent on other items or have risk considerations

  • Won't Have [Rank 76 - 100] These items likely have low benefit in comparison to the costs


Be sure that Backlog Grooming sessions align

with the timing of your prioritization sessions. #nbdleaves


Know that the prioritization forum is more than a meeting. It's an opportunity to develop relationships with your stakeholders. By communicating priorities, you are setting expectations. Delivering on these items creates trust. Eventually, you become more of a trusted adviser rather than a role. Once you have the respect of your stakeholders, you truly become the Product Owner regardless of your title.


  • The Scrum Guide

  • The Business Analysis Body of Knowledge (BABOK) v3

  • The 80/20 Rule And How It Can Change Your Life

#ProductBacklog #ProductOwner #prioritization #risk #cost #timesensitive #regulatory #compliance #MoSCoW #ParetoPrinciple

19 views0 comments

Recent Posts

See All
bottom of page