Managing Sprint Priorities

By Ken Hutchinson
Senior Program Manager

You and your team have worked hard with your stakeholders and developed a clearly articulated vision for your product. The roadmap has been given just enough size to get a decent idea of how many sprints you’re looking at, to deliver some pretty impressive value quickly.

Goals are clear. Team is focused.

But wait …

So, why are you suddenly getting hit with all kinds of scope creep in the middle of your first sprint? Can’t we even get through two weeks without someone trying to crash this plan? I mean, that’s why we do Scrum, isn’t it? Not only that, it looks like the next few product backlog items you’ll be refining in your next meeting don’t seem to align with your original vision for the product.

No matter how much organization (emphasis on lean planning), there is always that element of work that just gets lobbed at you and your team, seemingly from out of nowhere. It’s going to happen. How do you manage it without going completely off course?

At projekt202, we advocate building self-organizing Scrum teams for delivering software projects, whether they’re our teams or yours. From here on out, I’ll speak to managing priorities from a sprint team context, though it could be applied to any team using pretty much any framework or process.

Prioritization Categories

If you really do have a clear vision from stakeholders, and measurable goals for your sprint, then you may have what you need to help serve your team well to maintain focus sprint-to-sprint and, ideally, across your release.

The model I like to use is based on Stephen R. Covey’s Time Management Matrix from The 7 Habits of Highly Effective People.

The matrix is divided into the following four categories:

  1. Critical to address immediately
  2. Required to achieve our goals
  3. Interruptions external to the team that impact progress to our goals
  4. Distractions/time wasters

The categories are then mapped to Covey’s four quadrants:

  1. Urgent
  2. Not Urgent
  3. Important
  4. Not Important

Defining Priority

Now, how do you decide with your Product Owner which items map to each quadrant? Leaving it up to what feels right at the time will probably mean that the definition changes on a day-to-day basis, and you’re no better off than when you started.

Typically, I see work falling into these definitions:

Taking Action

Now we have an idea of what each category represents in real terms. Next, we need to decide what we’re going to do when a request meets one of these descriptions. To do that, I recommend the following strategies for each type:

  1. If the request is critical, just do it. It’s probably a critical production error that represents a full-stop by some members of the team to address before it cripples some part of the organization (you know, like your customer).
  2. Emerging requests that align to your goals should be evaluated and scheduled into the release against the current release plan.
  3. If not critical or important to include in the release, explore delegating the work to a more appropriate team. Maybe that group who wants a change to your app — to make their lives easier — is willing to make the change themselves; it can be scheduled in their backlog, as long as you peer review the change before it’s merged.
  4. Finally, when all else fails, don’t take on the request. If no one can justify it as urgent to the business (critical production issues) or important enough to assign release capacity (potentially at the risk of not delivering another PBI), then the team should be empowered to deny the request. Worst case, put in the backlog at the very bottom, if you truly can’t refuse, but it should be transparent to everyone that there is very little likelihood the team will ever get to this item, given the priorities above it.

Leveraging ALM Tools

At this point, you’ve got a lightweight method for grouping types of requests, complete with examples and an action plan for each. Chances are, you’re tracking your PBIs in a tool (e.g., CA Agile, JIRA, Microsoft TFS). A final step could be to map this matrix to your preferred backlog management tool using a modified MuSCoW prioritization.

Quadrant-1: Critical (P1)
Quadrant-2: Must (P2)
Quadrant-3: Could (P3)
Quadrant-4: Won’t (P4)


There are always going to be challenges to the scope of your current sprint plan and certainly along the release roadmap. Fortunately, Agile embraces this reality. Using this simple matrix, you can now have those conversations with your Product Owner or Stakeholders that welcome the new request. Just hold it up against each quadrant with them and ask them where they think this fits in and why. Often, they’ll realize quickly if the request is truly adding value, or if the request bears taking a second or third look.

To help you get started, use this sample matrix as a guide.

If you’re interested in reading more about writing user stories and backlog management, I recommend you visit my colleague Felice Brezina’s article, “When the Product Backlog is a Smoke Signal.”

Also, if you’re struggling to surface those opportunities that will become the foundation of your vision, projekt202 CEO David Lancashire gives a great walk-through of our approach to help get you there.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store