This is a re-post of an article first published on DZone.
Having worked with many Agile teams, I find that every team has a slightly different approach to prioritisation, 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 prioritisation, 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 prioritise during sprint planning.
Have you ever been stuck in a sprint planning meeting, where everyone has a different opinion of what to do first in a sprint?
Prioritisation is one of the most important aspects of any form of development work because choosing the right thing to do allows you to maximise 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 prioritisation but here are some general things you can do outside of sprint planning to help prioritisation decisions.
- Continually groom your product backlog.
- Apply learnings from the sprint review.
- Have a “Split of work” working agreement in place.
Continually Groom your Product Backlog
If at all possible, you should avoid the prioritisation 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 prioritising and refining the product backlog, through the practice of frequent (usually mid-sprint) “Product Backlog Refinement” session, means that sprint planning is less of a prioritisation 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 of 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.
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.
Future and Business: Work to get more customers in the future.
Past and Technical: Technical work that doesn’t bring in revenue but is important for maintainability, performance, and efficiency within the team.
Future and Technical: Forward-looking work with a technical slant such as upgrading to a new version of .NET.
From A Coach’s Guide to Mastering Backlogs by Karen Greaves and Samantha Laing
Questions to Ask During Sprint Planning
When it comes to prioritisation at sprint planning itself, here are some possible questions that can help guide your decisions.
- Which items provide the most customer value?
- Which items provide the most benefit to the business?
- What is the lowest-hanging fruit?
- Which items are the most risky?
- Which items result in the highest cost if not done now?
- What are the dependencies between items?
- Which items contribute most to our sprint goal?
Prioritise 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 need 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).
Prioritise 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 most risky?”
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 prioritise 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 prioritising the items that contribute most to the sprint goal.