Essential Checklist for Effective Backlog Refinement (and What To Avoid)
Let's talk about the backlog refinement process, once known as backlog grooming. You might know the Pareto principle and the philosophy of doing 80% of the work with 20% effort. It sounds wonderful, right?
On the other hand, refining a product backlog, updating backlog items and estimates might seem like a luxurious activity one postpones until they’re free from other activities in the agile process.
However, that’s not the case. Refining the backlog is indispensable. Sometimes, the power lies in the details, and with backlog management, that couldn't be truer.
Backlog refinement resembles great chefs developing their new recipes. 🍳 That's because besides details, refining a backlog demands a great deal of filling in the gaps and adjusting.
Join us as we discuss what refining a backlog entails. We'll look at what it is, its importance, the details of how to do it, and some key tips.
First things first, let’s look at what backlog refinement is.
Eliminate your flat backlog with
Easy Agile TeamRhythm
About backlog refinement
Backlog refinement is like pruning a plant: You discard the branches that are no longer necessary so you can help the plant grow the right way.
That means that you already have items in your backlog, but they might need some information or an update before they’re implemented. Also, some items might even need to be cut off from the backlog.
Refining the backlog saves time and money by ensuring that its items are ready for development at the right time. It also ensures that no customer-valuable item is forgotten. On the other hand, it guarantees that only customer-valuable items are implemented. All of this helps you retain customer focus.
Pick up your pruning shears, because we’re about to help you trim your backlog. ✂️
The Product Owner most likely schedules work sessions to refine the backlog.
These backlog refinement sessions should be regular, though you can refine the backlog more informally as long as it's an ongoing process. Besides the Product Owner, some of the Scrum team members can participate. Remember that the Development Team, the Scrum Master, and Product Owner are the Scrum Team. Although the Product Owner can update the backlog themselves, it's a great practice to involve the team.
Besides keeping the backlog up-to-date and complete, backlog refinement involves:
- Splitting broad user stories or other types of backlog items such as tasks or bugs, plus adding detail to them to improve comprehension
- Adding or reviewing estimates to issues, as estimation is crucial to sprint planning
- Ordering backlog issues to deliver high-priority ones in the next Scrum iteration
Important: Keep in mind that the customer ultimately determines the priorities. That’s one of the reasons why backlog refinement should be customer-centric (more on that later).
Tools that help you keep your backlog customer-centric will also help you deliver better for your customers. Easy Agile TeamRhythm lets you view your backlog and sprints in the context of the user story map, so you the whole team can see at a glance the work that is most important to your users.
Now that you know what refining a backlog is and who’s involved, let’s cover how to do it.
How to refine a backlog
There are so many ways of refining a backlog that it would be impossible to give you the best one.
- You could refine — split and detail — first and estimate second, starting with the least understood items first.
- You could estimate first to conclude on items that demand refinement before estimation and only then refine high-effort items if necessary.
- You could use a dedicated tool to help you refine or estimate, such as Easy Agile TeamRhythm, or you could just rely on a spreadsheet or a whiteboard and pen.
When refining the backlog, the Product Owner and the involved team members pursue the following goals:
- Make sure the backlog is accurate, which means that it contains all the necessary items.
- Maintain the prioritization of those items.
Ensure the delivery of the most important items, which should be on top of the backlog.
In the course of refinement, those involved might need to revive the product vision and the product roadmap. It might also be helpful to create user personas and define acceptance criteria, especially for item detailing.
Do you know what a backlog item ready for a sprint looks like? If not, develop a definition of done as well as a definition of ready. Then, to achieve item readiness, work out items such as:
- Sharing an understanding of the acceptance criteria
- Agreeing on a structure for the full description of different kinds of item
- Defining a clear view of dependencies between items
- Identifying the subject matter expert for each item
Finally, you should refine high-priority items first. Those are the ones developers will implement first in the next sprint.
Remember that backlog refinement is the set of all activities that have to do with managing backlog items. But there’s a thing: Backlog refinement doesn't have a time-box. According to the Scrum framework, it's not one of the Scrum events. Instead, it's a continuous crusade, and it's not necessarily a meeting (although it can be).
As you get used to backlog refinement, you can use the following questions to evaluate your progress.
Backlog refinement checklist
While goals are nice to have, you need to carry out specific actions to achieve them. So, here's a checklist that you must regularly go through. You can use it to either evaluate if the backlog needs refinement or confirm that refinement is done for the moment.
- Does the backlog contain user stories or other kinds of items that no longer make sense?
- Did you elicit any user need that's not yet in an appropriate form of backlog item?
- Does your customer expect you to implement any urgent item that's at the bottom of the backlog?
- Did the importance of delivering any item change since the last time you looked at the backlog?
- Does the backlog have any item for which no agile estimate exists?
- Is any estimate outdated?
- Is any backlog item too broad to understand what developers should implement in the next sprint?
You can only claim to have a refined backlog when you answer "No" to all the above questions. Until then, keep working on it, and avoid the below traps.
WATCH: Eliminate your flat backlog
What to avoid with backlog refinement
1. Ask more experienced team members to detail backlog items or provide estimates. For instance, junior developers aren't well-equipped to do this — talk with more senior team members about these topics.
2. Involve select team members. Talking with the entire team tends to just add noise. And, as we mentioned above, you should try to involve more experienced team members rather than more junior people.
3. Document your decisions. This is terribly important. Human memory is unreliable. So, to repeat good decisions and avoid bad ones, document both over time.
4. Do not excessively detail backlog items. Or you risk developers not knowing what to do with them. A great way to avoid this is involving some members of the Development Team in backlog refinement.
5. You shouldn't refine backlog items currently under development. You should refine the backlog for the next sprint or subsequent sprints.
6. Don't refine the backlog of the current sprint until it ends. You might feel tempted to only refine backlog items until the very last minute. That isn't good. Unexpected things happen, such as busy agendas, and discussions that take longer than anticipated...as a result, you might not deliver what's expected.
7. Avoid disagreements on estimates. That's usually a sign that refinement is lacking for that item. Listen to those people who suggest the highest or the lowest estimates. They're usually the ones who didn't understand the items because of either missing or too much information.
8. Get multiple people to weigh in on estimates. Although only asking one person may speed up the estimation, that doesn’t demonstrate a shared understanding. And that's something you should be keen about in backlog refinement.
If you’re unsure whether you need to do this process, take a look at the below benefits.
Best practices for maintaining a DEEP backlog
A truly effective backlog follows the DEEP principles - Detailed appropriately, Estimated, Emergent, and Prioritized. Here's how to operationalize these principles in your daily backlog management:
Detailed appropriately
- Progressive elaboration system: Implement a tiered detailing approach where items receive increasing levels of detail as they move up the backlog:
- Tier 1 (Top of backlog): Fully detailed with acceptance criteria, mock-ups, and technical notes
- Tier 2 (Next 2-3 sprints): Basic acceptance criteria and initial technical assessment
- Tier 3 (Further out): Minimal detail, just enough to understand scope and purpose
- Detail-level checklist: Create a standardized "detail sufficiency" checklist for each backlog item priority level:
High-Priority Item Checklist:
☐ Acceptance criteria defined
☐ UI/UX considerations documented
☐ Dependencies identified
☐ Technical approach outlined
☐ Testing requirements specified
- Just-in-time detailing sessions: Schedule 30-minute sessions dedicated solely to detailing specific high-priority items that are approaching implementation, focusing on one item at a time rather than trying to detail everything at once.
Estimated
- Estimation calibration workshop: Hold a quarterly calibration session where the team re-estimates a few completed items to check if their estimation accuracy is improving or needs adjustment.
- Confidence rating system: Alongside each estimate, include a confidence rating (High/Medium/Low) to flag items that might need re-estimation closer to implementation.
- Reference story library: Maintain a small set of reference stories with known estimates that new team members can use to calibrate their understanding of story points or other estimation units.
- Rotational estimation lead: Assign a rotating role of "Estimation Lead" who prepares estimation materials and facilitates discussion for complex items before the refinement session.
Emergent
- Backlog evolution timeline: Create a visual timeline showing how major themes in your backlog have evolved, helping stakeholders understand the natural emergence of priorities over time.
- Split/merge tracking: Track items that are frequently split or merged to identify patterns that might indicate improper scope definition or changing understanding.
- Innovation time box: Reserve 10% of each refinement session to discuss potential new backlog items based on recent customer feedback, market changes, or technical discoveries.
- Pruning protocol: Establish a clear protocol for archiving or removing backlog items that haven't moved in 3-6 months, requiring explicit justification to keep items that remain stagnant.
Prioritized
- Multi-factor prioritization framework: Create a simple scoring system that considers business value, customer impact, technical risk, and strategic alignment when prioritizing items.
- Priority horizon planning: Define clear "priority horizons" where items are grouped by implementation timeframe (Now, Next, Later, Future) rather than trying to maintain a perfectly ordered list of 100+ items.
- Stakeholder priority alignment check: Conduct a monthly alignment check where key stakeholders review the top 10-15 backlog items to ensure prioritization still reflects current business needs.
- Urgency vs. importance matrix: Use a 2x2 matrix to visually map items based on urgency and importance, helping distinguish truly high-priority items from merely urgent ones.
The value of refining your backlog
Backlog refinement can save you time and money. Back in the old days, someone would basically engrave a requirement specification document in stone before development. With the rise of agile, that's ancient history.
A backlog contributes massively to the success of an agile project. It’s a living document, which means it changes over time. But while it changes, it must remain accurate. And there are no strict rules when it comes to refining a backlog. That means, for instance, that not every item requires detail.
However, the Product Owner should guarantee that the backlog items are ready for scheduling. 📅 And without backlog refinement, that would be a Herculean task.
Imagine meeting a sprint goal without:
- Enough information about backlog items or items with heavy, complex descriptions
- Outdated estimates or no estimates at all
- High-priority items forgotten at the tail of the backlog
- Items that reside only in people's heads or no longer represent value to the customer
Here’s what you would face:
- Crazy development calendars
- Undelivered items
- Items delivered late
- Insane budgets
That wouldn't definitely be a good prognostic for customer retention.
Bridging customer-centricity with your backlog structure
While most teams claim to be customer-centric, truly embedding customer needs into the fabric of your backlog requires systematic approaches:
Persona-driven backlog organization
Create a backlog structure that explicitly connects items to customer personas and journeys:
- Persona tagging system: Implement tags or custom fields in your backlog tool that associate each item with specific user personas (e.g., "Power User Sarah" or "New Customer Alex").
- Customer journey alignment: Map backlog items to specific stages in the customer journey, ensuring you're addressing needs across the entire experience.
- Persona-based filtering: Set up backlog views filtered by persona to periodically check if you're neglecting certain user types.
Voice-of-Customer integration practices
Establish regular rhythms to incorporate customer feedback directly into backlog management:
- Customer insight review: Schedule a monthly session where customer support logs, user research, and analytics are reviewed specifically to identify potential backlog additions or reprioritizations.
- Outcome-based grouping: Group backlog items by customer outcomes rather than features, helping the team focus on what customers want to achieve rather than specific implementations.
- Customer verification points: Mark specific high-impact backlog items for direct customer verification before implementation, creating a feedback loop that validates your understanding.
Customer value assessment framework
Implement a lightweight framework to assess customer value:
Customer Value Scale (1-5):
1: Nice to have, minimal user impact
2: Solves minor pain points for some users
3: Notable improvement for many users
4: Significant value add for core users
5: Game-changing capability for majority of users
Balancing detail: How to avoid over-refinement and under-refinement
Finding the right level of detail is crucial for efficient backlog management - it is a delicate balancing act, but with the right frameworks in place, you should be able to easily find your footing. Here are some ideas:
The "Just-Right" detailing framework
Implement a visual system in your backlog tool to indicate detail status:
- Red: Under-refined, needs substantial work before sprint planning
- Yellow: Partially refined, key questions remain
- Green: Appropriately detailed for its current priority
Detail radar chart
For complex items, use a simple radar chart to assess completeness across different detail dimensions:
- Functional requirements
- Technical considerations
- Edge cases/exceptions
- UX/UI specifics
- Testing approach
Time-boxed refinement protocol
Establish time limits based on item size:
- Small items: Max 15 minutes of refinement time
- Medium items: Max 30 minutes
- Large items: Max 60 minutes (or consider splitting)
If an item can't be sufficiently refined within these timeboxes, it's a signal that either the item is too large or fundamental understanding is missing.
Progressive detail thresholds
Define clear thresholds for when to increase detail:
- When an item moves into the "Next 2 Sprints" zone: Ensure all acceptance criteria are defined
- When an item moves into the "Next Sprint Candidates" zone: Add technical approach and testing strategy
- When an item is selected for upcoming sprint: Final detail check with implementation team
Documenting backlog decisions for traceability
Finally, create a system that preserves the context and reasoning behind backlog decisions.
Decision log integration
Maintain a lightweight decision log directly linked to backlog changes. It would look something like this:
Backlog Decision Log
Date: [Date]
Item: [Item ID/Name]
Decision: [Prioritization change, scope modification, etc.]
Rationale: [Business context, customer feedback, technical constraints]
Stakeholders: [Who was involved in or informed of the decision]
Impact: [What other items or timelines are affected]
Backlog item history annotations
Use comments or a history section in each backlog item to document significant changes.
- Priority changes (and why)
- Scope modifications
- Estimation adjustments
- Dependencies discovered
Backlog review snapshots
Take periodic "snapshots" of your backlog's top 20 items and save them with dates, to give you the historical context on how priorities have evolved.
Transition criteria documentation
Explicitly document the criteria that moved an item from one state to another.
- Why was this item pulled into the sprint?
- Why was this item deprioritized?
- Why did the estimate change significantly?
Regular backlog health audits
Implement a systematic approach to maintaining backlog health over time.
Monthly backlog health checklist
Date: [Date]
Auditor(s): [Names]
Items Review
- [ ] Items older than 6 months reviewed and updated/archived
- [ ] No orphaned items (all connected to epics/themes)
- [ ] All high-priority items have sufficient detail
- [ ] Acceptance criteria consistent across similar items
Metrics Review
- Backlog growth rate: [%]
- Item completion rate: [%]
- Average time in backlog: [Days]
- Estimation accuracy: [%]
Balance Review
- Technical debt vs. feature work balance: [Ratio]
- Distribution across strategic themes: [Analysis]
- Distribution across customer personas: [Analysis]
Action Items
1. [Action]
2. [Action]
3. [Action]
Backlog vitality score
You can even create a simple scoring system (0-100) for backlog health based on factors like:
- Freshness (when items were last updated)
- Detail quality
- Prioritization clarity
- Strategic alignment
- Technical debt balance
Track this score over time to identify trends.
Staleness detection automation
Set up automated flagging for potentially stale backlog items.
- No activity in 90+ days
- No recent changes despite being high priority
- Estimates or technical approaches that predate major system changes
Backlog refinement is an essential process
If you think of space missions and compare them to backlog refinement, the backlog is your mission guide. 🚀 And unless you have a refined backlog, your mission guide will get you no farther than your backyard. 😨
Backlog refinement should help you in your quest to have a permanently relevant set of items in your backlog. And by relevant, we mean complete, valuable, detailed yet straightforward, recently estimated, and correctly ordered.
While it’s VERY easy to forget about the importance of backlog refinement, don't. Focusing on the current sprint is essential, but delivering a satisfactory product is the most important thing. And an appropriately refined backlog helps team spirits.
Additionally, you don't want to be that Product Owner who gets a bucket full of questions during a sprint planning meeting. That's a strong indication that backlog refinement failed epically.
Easy Agile TeamRhythm can help you refine user stories by enabling you to:
- Register estimation in user stories
- Drag and drop user stories to prioritize by customer value and business value
Try out these tips during backlog refinement. We’re sure you’ll love it, and if you need a hand, we’re here and happy to help.
Related Articles
Agile Best PracticeDEEP: The 4 Characteristics of a Good Product Backlog
A product backlog represents all of the goals and desired outcomes within the development of a product. They are the specific tasks a team hopes to complete when they set out to design or improve upon a product.
What makes a product backlog so effective is its agile nature. Backlogs are in constant evolution, changing and adapting based on the current needs of stakeholders and customers. To keep a backlog up-to-date and in its most effective form, it needs to be continuously refined and adapted. This process takes time, but there are simple, powerful strategies for maintaining a quality backlog.
A good product backlog has four characteristics. It is:
- Detailed appropriately
- Estimated
- Emergent
- Prioritized
We’ll cover all of these attributes in detail, including how you can ensure your product backlog is in good health. But first, let’s get on the same page about product backlogs and the refinement process.
Transform your flat product backlog with
Easy Agile TeamRhythm
What is a product backlog?
A product backlog is a prioritized and ordered list that represents the work to be completed by a development team. Backlog items are derived from the product roadmap and are organized based on the tasks that are most vital — the ones that will make the biggest impact at any given time.
Backlog items represent what it will take to develop a new product or improve an existing one with new features. It’s all of the work a team will tackle in the future, but it’s also a flexible, living organism that evolves as a development team learns more about the product and its stakeholders.
The product owner is in charge of ordering and prioritizing backlog items, placing high-priority items at the top. They are also responsible for backlog refinement, which ensures all backlog items are organized, have appropriate details, and are ready for any upcoming sprint planning.
Product backlogs vs. sprint backlogs
Sprint backlogs are quite similar to product backlogs, but they serve a different, more specific purpose. At the beginning of a Scrum, the product owner arranges the product backlog items that are to be completed by the Scrum team in that sprint.
The Scrum product backlog represents a small subset of the overall product backlog. The product backlog is the entire bottle of wine, while the sprint backlog is the glass of wine you’re going to tackle next. In this analogy, the Scrum master is the sommelier, providing guidance, context, and feedback throughout the sprint.
At the end of the sprint, a sprint review is conducted with the stakeholders to better understand what to tackle next. Backlog items that weren’t completed may be pushed back into the larger product backlog to get to at a later date or during the next sprint. Another sprint planning meeting will prepare the team to tackle the next batch of backlog items.
Why does a backlog need refinement?
Backlog refinement isn’t a luxury task reserved for when you get a chance to tidy up. Refinement is a key part of product backlog management that ensures a backlog always has the most recent, up-to-date information.
Refining the backlog prepares it for the development team, saving time in the long-run. The process helps to prioritize items and ensures there’s nothing in your backlog that you no longer need.
As you’re well aware, the agile methodology centers around flexibility and the ability to evolve a plan as new information or roadblocks appear. What you thought was important at the beginning of product development may not be necessary anymore, or your stakeholders may have turned you in a completely different direction.
Product backlog refinement includes:
- Adding detail to high-priority backlog items for greater comprehension.
- Improving and reviewing estimates.
- Removing items that are no longer relevant to the product.
- Adding items based on new stakeholder feedback.
- Making adjustments based on the most recent bug fixes.
- Prioritizing items that bring customer value.
- Ordering backlog items to deliver the most impact over the next sprint.
Backlog refinement takes time, but it’s well worth the effort to have a healthy, up-to-date backlog that’s always ready for the development team.
DEEP: The key attributes of a good product backlog
Roman Pichler, the author of Agile Product Management with Scrum: Creating Products That Customers Love, developed DEEP to describe the key attributes of a good product backlog. The acronym DEEP helps product owners and development teams understand how to make smart decisions while maintaining a successful backlog.
The concept is applied throughout the product backlog refinement process, which is a critical part of backlog management. Backlog refinement, previously called backlog grooming, is an ongoing process that ensures a backlog is in tip-top shape. We like to think of it like trimming the branches of a plant.
To help a plant grow, you need to prune and trim it. The refinement process adds details where needed and prioritizes items based on the current information a product owner has from team members and stakeholders.
DEEP stands for Detailed appropriately, Estimated, Emergent, and Prioritized.
Following these guidelines and best practices will lead to a quality backlog, which will lead to smooth product development and a successful end result. Let’s dig into each attribute. 🔎
Detailed appropriately
Details matter, especially as a user story rises in priority. As a backlog item gets closer to being completed or moved into a sprint backlog, it requires more detail. Upcoming backlog items should be detailed appropriately, so they can be better understood by the development team. The closer an item is to being completed, the more detail it should have.
On the other hand, items that are lower on the priority list don’t require nearly as much detail. It’s a poor use of time to add details to lower priority items since you never know how the backlog is going to evolve. You could waste a lot of time detailing low-priority items when they might be removed or revised later on in the process.
Estimated
Thorough estimation should be focused on high-priority items that will be tackled soon. As you refine your backlog and add more details to top-priority items, you can improve your estimation. A good option is using story points to zoom in on the details. They can help you accurately and practically reflect the reality of an item from the customer’s perspective.
📘 Read our guide to incorporating user story points to start using this technique.
Since not much is known about them, it’s difficult to properly estimate items that are lower in priority. When you are further down the priority list, your estimation will be more of a guess since you don’t have all of the information yet. In these cases, use a simple agile estimation technique, such as t-shirt sizing (labeling work items as XS, S, M, L, XL) to make a guesstimate. Based on the information you have at that moment in time, make an approximate estimate on the exertion required for that backlog item.
Emergent
The more you learn about the product and its customers, the more you can improve your product backlog. The backlog is a living document that represents your plan at any one given time. It’s not set in stone, and it should see revisions and improvements as you go.
With the information gleaned from retrospectives and stakeholder feedback, you can update the backlog to reflect what you’ve learned along the way. Allow your backlog to evolve, adding, removing, and refining items as needed.
Prioritized
A product backlog needs prioritization. Items at the top are a higher priority, and items toward the bottom are a lower priority. When deciding which items should be prioritized, consider the value each item will provide.
Your team can maximize its efforts by prioritizing the backlog items that will provide the most value to customers at any given time. Since this will change depending on the current needs of your customers, you need to continually adjust and refine your priority order.
Achieve a DEEP product backlog with Easy Agile
Easy Agile is dedicated to helping agile teams work more effectively. We have a suite of Jira apps designed for teams that want to develop products that put the customer at the forefront of decision making.
Easy Agile TeamRhythm transform your flat product backlog, prioritizing based on value to the customer and bringing the customer journey to life. They help teams organize and prioritize user stories while visualizing the customer journey. Keeping your customers embedded in your process will help you make refinement decisions that are in the best interest of the customer, no matter what phase of development you’re in.
Learn more about our agile apps and follow our blog for the latest content for Jira teams.
Agile Best Practice5 Agile Estimation Tips To Help With Backlog Prioritization
Backlog prioritization is a never-ending task for product owners and product managers. As priorities evolve in response to changing business needs, or even as work is completed, or adjustments to team resourcing are made, it's important to maintain focus on the work that will deliver the most value by keeping your backlog in good shape. Agile estimation techniques can make prioritizing your backlog faster and easier.
So, let's take a look at some specific methods to prioritize your backlog and see how agile estimation can help deliver the most value to your end-users and stakeholders.
5 ways to prioritize a backlog
Of course, there are more than five ways to prioritize work items in a backlog. But, we've picked a few of our favorites that, when combined with an agile estimation process, help keep our product backlog prioritized so we can breeze through sprint planning.
1. Weighted Shortest Job First
Wow, is that a mouthful! Let's use the "WSJF" acronym to refer to this SAFe technique. Not as intimidating as it sounds, WSJF is a simple formula that assigns a business value to product backlog items.
WSJF = Cost of Delay ÷ Job Duration
Cost of Delay is the sum of three relative metrics:
- User/Business Value: the relative importance of the work item.
- Time Criticality: the decline of user/business value over time.
- Risk Reduction: the reduction of business or technical risk.
To determine the relative size for Cost of Delay, think of the lowest business value, the smallest decline in value over time, and the least risk reduction as a 1 value. The same as with Fibonacci sequence story point estimation, adjust that score appropriately when comparing work items to score them relative to one another.
The Job Duration is also expressed in relative terms. If you estimate your work items using relative estimation with story points, the story point value equals the Job Duration.
If you're using this technique to prioritize a large amount of work in a backlog where some items have only been t-shirt sized, convert your t-shirt sizes to standard Fibonacci numbers and use that value.
Warning: Be careful with converting t-shirt sizes to story points. You'll need a way to flag the t-shirt size work items that you converted to story points. You and your Scrum Master need to recognize those as t-shirt level estimations rather than the real story point estimates that come with fully refined work items.
See more at a glance in Easy Agile TeamRhythm, to make prioritizing your backlog faster
💡Tip: Add up to three extra fields on issue cards
2. MoSCoW
Must-have, should-have, could-have, and won't-have are the buckets used to prioritize a backlog with the MoSCoW technique. The product team defines these designations based on the product's unique features and competitive offerings.
Each work item falls into one of those categories. The easiest part of this process is sending Won't-have items directly to the trash and getting them out of your way. Next, prioritize must-haves first and then should-haves. The could-have items naturally fall to the bottom of the backlog.
Take these items through your regular refinement meetings with your team members, and assign each item a t-shirt size or story point value. You're then ready to add the right amount of work items to your sprints or releases based on your teams' velocity or the number of story points they expect to finish during a sprint.
3. Kano
The Kano model of prioritization uses five classifications:
- Must-be: the basic functionality that your users expect.
- Attractive: a pleasant surprise for your users, but no one is going to be upset if it's not there.
- One-Dimensional: work items that make your users happy and will disappoint them if they aren't part of your product.
- Indifferent: work items that are unimportant to your customers. Often, these work items represent technical debt or enhancements that help the software development team develop more efficiently or work in the latest versions of their tech stack — but your customers really don't care about them.
- Reverse: the process of undoing a previous feature or update. If you've ever built a feature or made a UI update that your users hated, you understand reverse work items. Oops. Unfortunately, sometimes these are necessary evils, especially when it comes to security features or transitioning users to a new product after retiring a legacy product.
Like the MoSCoW method, you'll estimate these work items during refinement and then add them to your iteration or release plan. But, different from MoSCoW, you may want to balance out your sprints and releases with work items from each classification.
4. Stack Ranking
The most brutal of all prioritization techniques, stack ranking forces teams to have a linear rank of work items, which means there is only one top priority, one second priority, one third priority, and so on. Brutal!
Once you get used to it, stack ranking is a useful way to force product managers to make tough choices between work items. Even if two work items can be completed during the same sprint, it's up to the PO to determine which one gets done first, and then that choice is reflected in the sprint backlog.
Often, this job becomes easier when it's put in dire terms. For instance, if you only had one day to attract new users to your product, what work would you want in production? BOOM! There's your top priority.
The nice thing with stack ranking is that it allows POs to slide smaller work items into current sprints when other higher-priority work is too large. Adding the larger work item over-commits the team based on their velocity. Those small work items serve to fill up sprints so teams can maintain velocity and be as productive as possible. So, just because a two-story point work item is two-thirds the way down the backlog doesn't mean it will never get done.
5. Story Mapping
Story mapping helps you visualize the customer's journey through your product from start to finish. (Yep, we stole that straight from our other excellent article on story mapping.) For advanced story mappers, take what you’ve learned about story mapping, and think about how you can add MoSCoW or Kano techniques to your story maps.
Perhaps your epic backbone at the top of the user story map could represent the buckets in the MoSCoW method?
If you're like us, your story mapping sessions are productive brainstorming activities, and you'll leave the sessions with way more work than you can accomplish. By applying MoSCoW or Kano principles to the stories in your user journeys, you’ll discover the most important stories to prioritize and the stories that can wait for a later release.
Building agile estimation into backlog prioritization
We've given you five different techniques to corral your work items into an organized, prioritized, value-delivering product backlog:
- Weighted Shortest Job First
- MoSCoW
- KANO
- Stack Ranking
- Story Maps
We've also shown you ways to incorporate agile estimates like t-shirt sizes and story points into your prioritization process to keep your team delivering the most important work while maintaining velocity and dazzling your customers and stakeholders.
We encourage you to take these ideas, share them with your team, and give them a try. If you need help using the Story Map concept, try Easy Agile TeamRhythm. However your team prioritizes its product backlog, remember to put the most important work first and then adjust those priorities as needed. Keep it easy and keep it agile!
WorkflowThe Difference Between a Flat Product Backlog and a User Story Map
It’s one of the most common practices in agile software development; the flat product backlog. We’ve all seen them, we’ve all contributed to them, and we’ve all inevitably drowned in them.
In its simplest form, a flat product backlog is a laundry list of ‘stuff to do’ that will ultimately provide value to the customer. These actionable items are prioritised (top to bottom) in the order the value will be delivered. If a team is adopting the Scrum method the backlog is split into future sprints to provide an indication of what will be delivered and when.
Depending on the size and requirements of the organisation, the list of things to be done could be 10, 100 or 1,000 actionable items. It’s easy to see how managing the latter comes with the challenges of updating, assigning, grooming and scheduling these items.
What’s Wrong With Flat User Story Backlogs?
So far we know that flat backlogs represent a list of things to be done. This comes with its challenges, and its shortcomings were best described by Jeff Patton when he said;
We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.
After all that work, after establishing all that shared understanding, I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.
That’s what a flat backlog is to me. A bag of context-free mulch
How do you pick an item from a list, and deem it the thing that’s going to provide the most value to your customers, without that additional context?
Shortcomings of a Flat Product Backlog
- The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product
- Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does
- The flat backlog provides no context or ‘big picture’ around the work a team is doing
- A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories
- Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?
User Story Maps
A story map is a visual representation of the journey a customer takes with a product, including the activities and tasks they complete. This visualisation helps the team to focus development on providing the most value to customers and their desired outcomes.
It provides context for teams by answering the following questions:
- Why are we building this?
- Who are we building this for?
- What value will the solution provide for the customer and when?
The story map still showcases the ‘stuff to be done’, the difference here though, is the way in which this information is visualised. As you can see, rather than listing these items out, each item is contextualised under a bigger piece of work. Besides the way the information is visualised, the key difference between a flat product backlog and a user story map, is the focus on the customer journey. Let’s unpack this by breaking down the anatomy of the user story map.
What A User Story Map Achieves that a Flat Product Backlog Can’t
- Focus on Desired Customer Outcomes: the visualisation of the customer journey allows teams to identify and implement features based on customer outcomes, and track progress at a glance against a story map
- Bring the Customer Journey to Life: the transformation of the flat product backlog to a customer centric story map means teams have a better understanding of their customer journey and what their customers want and value
- Prioritising Actions Based on Value to the Customer: visualisation of the customer journey allows teams to prioritise work based on “value to customer”, resulting in better outcomes and less waste
Are you getting lost in your flat product backlog? Are you stuck in an endless development cycle, but not really sure for who or why your building features?
Easy Agile TeamRhythm
Easy Agile TeamRhythm supports User Story Mapping, sprint or version planning, backlog refinement, and team retrospectives.