Solving Your Prioritization Conundrums

Bart has been in ecommerce for over 20 years, and can't imagine a better job to have. He is interested in all things agile, or anything new to learn.

  Risk Management   Strategy  

Here’s an interesting dilemma to consider. An organization has an SLA on fixing defects with the product, and the SLA changes based on the severity of the issue itself. For instance, p1 issues that are in production have a “fix SLA'' of 48 hours, while p5 problems have an SLA of 60 days, and there is a sliding scale in between.

This seems perfectly reasonable when you think about it. The important items are done first, and the less important things can wait until later. But what happens when “later” arrives? Should the team pivot and work on the low-value item, simply because it is old?

This kind of situation, which seems to make a lot of sense at first glance, actually creates a lot of problems with your team's ability to prioritize.

Imagine you are a team about to do sprint planning. You have a list of stories and defects that you could work on, but based on story point value and velocity, there’s no way you can take on all of them; you have to choose what to do. Most processes and most product owners would give you a clear message: do the highest value thing first, no matter the age of the request.

Universally, this is good advice. A team is unlikely to get into much trouble by focusing on value to the customer or the business as a first-order priority. But that still leaves a stakeholder issue; someone is waiting for a …

Please log in or sign up below to read the rest of the article.