Skip to main content

How to approach two requirements with same priority

Last post 07:09 pm September 30, 2024 by juni pereva
5 replies
06:22 am September 25, 2024

If any two requirements fall under the same priority, what is the best approach to choose one, how to convince the stakeholder and what is the best practice, please suggest 


05:32 pm September 25, 2024

In Scrum, the requirements - the work that the team needs to do to improve the product - are captured in the Product Backlog. The Product Backlog is a list of work items, or Product Backlog Items, for the Scrum Team to work on. Since it's a list, two items cannot occupy the same spot on the list. The Product Owner is accountable for managing the Product Backlog, including ordering the Product Backlog Items. If anyone disagrees with the order, the Product Owner doesn't have to convince that person. Instead, that stakeholder must convince the Product Owner to make the change.

But, on a more practical level, in my experience, priority isn't a continuum. There are often discrete priorities, usually 3 or 5. It's not uncommon for many items to have the same priority. But also, priority isn't the only attribute to consider when ordering work. Value is another attribute. In some cases, the estimated effort could be another attribute. Considering dependencies between Product Backlog Items could also be valuable. Depending on your context, there are probably other factors or attributes beyond priority to consider when arranging the work. Regardless of the factors, the ultimate accountability for the ordering rests with the Product Owner. Anyone wishing to change the order must work with the Product Owner to hear their views.


05:33 pm September 25, 2024

Which of them would best serve a Sprint Goal which mitigates a significant risk or uncertainty, and makes it worth Sprinting at all? Scrum is about learning to build the right thing at the right time.


03:27 pm September 26, 2024

Priority is relative.  For example, in a financial application, giving the ability to filter transactions could be be high priority for tax season in the United States.  Upgrading the version of the database so that security issues can be addressed is a high priority.  Providing the ability for the customer to view the user interface in multiple languages could be a high priority.  But which of those provide the highest value? Which of those would be the least amount of work for the Developers to implement? Which of those if not done would cause the most stress? 

Trying to rank work based upon a single indicator is usually going to cause more questions and frustrations than it satisfies. Sure it is easy to have the software you use to keep track of the Product Backlog sort by a numeric value.  But that isn't maintaining the list of work that is needed in an effective manner. 


08:06 am September 30, 2024

But which of those provide the highest value? Which of those would be the least amount of work for the Developers to implement? Which of those if not done would cause the most stress? 

Agree with Daniel on the above point and it is the best way to look at it. The technique in Scaled Agile is called Weighted Shortest job first (you could read about it). The idea is to deliver the most valuable item in the shortest duration which provides the best economic return. You will have to work with your Product owner and set the priority accordingly.


09:24 am September 30, 2024

When you have two requirements with the same priority, here are some effective strategies to approach them:

  1. Assess Impact: Evaluate the potential impact of each requirement on the overall project goals. Which one contributes more significantly to user satisfaction or project success?
  2. Stakeholder Input: Consult with stakeholders to gather their perspectives. Sometimes, discussions can reveal preferences or additional insights.
  3. Resource Availability: Consider the resources (time, skills, tools) required for each requirement. If one is easier to implement with available resources, it might be wise to tackle that one first.
  4. Dependencies: Check for dependencies between the requirements. If one requirement unlocks or facilitates the other, prioritize it accordingly.
  5. Timeboxing: Allocate a specific amount of time to work on both requirements simultaneously. This way, you can make progress on both without fully committing to one.
  6. Iterative Approach: If possible, implement a minimal viable version of each requirement and gather feedback. This could help you decide which direction to take next.
  7. Risk Assessment: Analyze the risks associated with each requirement. Prioritize the one with lower risk or that can mitigate a larger risk.
  8. Sequential Approach: If it makes sense, plan to complete one requirement before starting the other, ensuring that you can maintain focus and quality.

By carefully weighing these factors, you can make an informed decision on how to proceed with both requirements.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.