In Sprint Planning, How Do You Prioritize the Requirements in the Backlog?

Background

Having worked with many Agile teams, I find that every team has a slightly different approach to prioritization, and some teams are better at it than others. I’ve recently observed a Sprint planning session where a team couldn’t agree on priorities, and it was an unpleasant place to be. My mission in writing this article is, therefore, to share some personal experiences with prioritization, specifically some techniques and considerations during and outside of Sprint planning. I hope that these suggestions can help you avoid the sticky situation of not knowing how to prioritize during Sprint planning.

Why Prioritize?

Have you ever been stuck in a Sprint planning meeting, where everyone has a different opinion of what to do first in a Sprint?

Prioritization is one of the most important aspects of any form of development work because choosing the right thing to do allows you to maximize the value delivered in a Sprint. Having a shared understanding of priorities empowers a team to move in a uniform direction towards a common goal.

Outside of Sprint Planning

There isn’t a “one-size-fits-all” approach to prioritization but here are some general things you can do outside of Sprint planning to help prioritization decisions.

1. Continually groom your product backlog.

2. Apply learnings from the Sprint review.

3. Have a “Split of work” working agreement in place.

Continually Groom Your Product Backlog

If at all possible, you should avoid the prioritization conundrum in a Sprint planning meeting. Remember, the Product Backlog is shaped like a triangle, with the most refined and high priority user stories on the top of the backlog, and the least important and least refined epics on the bottom. Continually prioritizing and refining the product backlog, through the practice of frequent (usually mid-Sprint) “Product Backlog Refinement” sessions, means that Sprint planning is less of a prioritization discussion than a “what’s the best way to do the work” session.

Apply Learnings From the Sprint Review

It’s important to consider the feedback from a Sprint review. They could invalidate the top items in the product backlog, making for an unfruitful Sprint planning session. By feeding these learnings into your product backlog, you will ensure that the product backlog items are always relevant when it comes to time for Sprint planning.

Have a “Split the Work” Agreement In Place

Create a working agreement that defines what proportion of a team’s time should be spent on a particular type of work. For example: “Surprise and Delight” type work versus “Maintenance” versus “New Features.”

In their book, A Coach’s Guide to Mastering Backlogs, Karen Greaves and Samatha Laing describe any type of work to be largely classified as one of four types.

1. Past and Business: work on existing features, or items that customers would care about. This type of work focuses on the retention of customers versus getting new ones.

2. Future and Business: work to get more customers in the future.

3. Past and Technical: Technical work that doesn’t bring in revenue but is important for maintainability, performance, and efficiency within the team.

4. Future and Technical: Forward-looking work with a technical slant such as upgrading to a new version of .NET.

Questions to Ask During Sprint Planning

When it comes to prioritization at the Sprint planning session itself, here are some possible questions that can help guide your decisions.

1. Which items provide the most customer value?

2. Which items provide the most benefit to the business?

3. What is the lowest-hanging fruit?

4. Which items are the riskiest?

5. Which items result in the highest cost if not done now?

6. What are the dependencies between items?

7. Which items contribute most to our Sprint goal?

Prioritize by Customer Value

Ask: “Which items provide the most customer value?”

Working this out is simple, and can be done in several ways, such as having a verbal discussion, validating the user needs through user testing, and surveying what current solutions lack through market research. You can simply have a discussion around those activities or use a framework such as “Importance versus Satisfaction.” Dan Olsen describes the framework in his book, The Lean Product Playbook, as a useful one for thinking about how to create customer value in a rigorous, analytical manner.

The framework compares Importance (the measure of how important a particular customer need is to a customer) and Satisfaction (how satisfied the customer is with a current solution that provides customer benefit).

Prioritize by Business Value

Ask: “Which items provide the most benefit to the business?”

Business value is the cumulative sum of things that affect the health of a business. It entails many things such as Shareholder Value and Customer Value.

Ensure that every piece of work has its business value articulated. One of the most common faults of development teams is not articulating the business value of technical debt (the “Past and Technical” work as referred to by Karen Greaves). As a delivery manager, I always encourage my teams to use simple one-liners. “Create a separate database” becomes “Create a separate database because the tight-coupling makes it time-consuming to make changes.”

Factor in the Estimated Effort to Do the Work

Ask: “What is the lowest-hanging fruit?”

Factor in the effort for a piece of work into the discussion. Tackle the “low-hanging fruit.” If two pieces of work are of comparable business value, pick the one with less effort.

Mitigate Your Risks by Tackling Risky Items First

Ask: “Which items are the riskiest?”

Look ahead and consider de-risking high-risk pieces of work by doing a “spike” (an investigation or proof-of-concept). You may want to prioritize higher risk items to mitigate the risk early on in a project or Sprint.

Consider the Cost of Delaying a Piece of Work

Ask: “Which item results in the highest cost if not done now?”

Consider the cost of not doing certain items, such as loss of competitive advantage, or inability to use a new piece of technology further down the line.

Identify Dependencies to Work Out a Natural Order of Priorities

Ask: “What are the dependencies between items?”

There may be a natural order in which items need to be completed. For example, you might need to do a user survey to sound-check a new layout before implementing it.

Determine What Items Contribute Most to Achieving the Sprint Goal

Ask: “Which items can help us best achieve our Sprint goal?”

Last but not least, remember that Sprint planning should happen around a Sprint goal. Every item in a Sprint backlog contributes to the Sprint goal, some more than others. Consider prioritizing the items that contribute most to the Sprint goal.

About the Author

Zhi Lee is the owner of Teamworx, a consultancy based in Auckland that provides Agile Coaching services.