Prioritize Backlogs with the User in Mind
Prioritize Backlogs with the User in Mind
Handling prioritization in the product backlog is not easy. A perfect solution will, if it exists, look different from company to company.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Handling prioritization in the product backlog is not easy. A perfect solution will, if it exists, look different from company to company. All organizations have their own individual business needs, product architectures and organizational structures to consider when deciding how to do this. In addition, backlog prioritization influences people in different roles and a good solution should account for the needs of both developers and product owners. This article presents a scenario requiring backlog prioritization on several levels and should be a good read for any product owner or developer interested in effective backlog management.
Imagine this scenario:
- You are developing a product with several features. Some are crucial, some are nice-to-have. Prioritization of features is the product owner’s responsibility and is driven by business value.
- Each feature is comprised of user stories. Prioritization of user stories is determined via collaboration between the the product owner and the team, influenced by business value and technical logic.
- Agility is required. You must be able to update feature and user story priority continuously.
- The majority of your teams are feature teams* but you have one component team** that will work on select stories from several features.
How will you manage prioritization for this product?
In the illustration above, features take the form of different sized spheres, laid out on an axis that represents their respective priority. Features to the right have higher priority than features to the left.
The colored fields in red, yellow and green represent the share of Must, Should and Could priority of the stories that constitute the features. The user stories that should be handled by the component team are marked with stripes.
When managing the backlog for this scenario you should remember that people in different roles in the project have different needs. A good solution will take into account the needs of all involved stakeholders.
The Product Owner
Starting from the product owner perspective, we should accommodate the need for continuous priority changes on feature level. To ensure this, there are a couple of recommendations to consider:
- Allow feature priority to be independent from user story priority. The product owner should be able to adjust feature priority as needed.
- Changes in feature priority must be communicated to ensure team execution aligns with product owner vision, and enable effective backlog grooming by the team.
- Minimize the amount of features that are worked on simultaneously in order to reduce the risk of wasted effort.
- When possible, have no more than one team working on a feature as this increases the team’s sense of ownership for the feature.
The Feature Teams
The feature teams have interests like avoiding multi-tasking (pushing to complete several features at the same time), influencing what sequence user stories should be worked on and keeping things simple. To support them, consider this:
- Allow them to work on one feature at a time.
- Respect the boundaries of sprints when reprioritizing features. Frequent changes frustrate teams.
- Be transparent but do not over communicate about what features might come in the distant future. In most cases, what’s next is the only thing that is important.
- The team will know in what sequence stories should be worked on from a process and a technical perspective. These aspects should, in addition to business value, influence in what order stories are tackled to avoid bottlenecks and account for dependencies.
The Component teams
The component team has to live with the reality of working on stories from several features simultaneously. To ensure your component teams are working on the right stuff, consider the following:
- Allow them to work on stories from several features in parallel.
- Clearly communicate feature priority; component story priority should follow closely.
- Dictated by the feature priority, the component team should have a very strong influence on the priority of component stories so that they, for example, can deal with all upcoming stories from a particular part of the code base at the same time.
It will pay off to think through and design a system for backlog prioritization that fits the needs of your company and the people working there. Process aside, it will help to be equipped with an Agile tool that can handle dynamic prioritization on several levels. For concrete training on how to do this in Hansoft, please view this tutorial video.
* Feature Team: A feature team has a diverse set of skills and is capable of delivering complete features by their own devices, without dependency on external teams.
*Component Team: A component team specializes on a particular piece across several features being developed, often creating a dependency for teams who otherwise could deliver a full feature.
Opinions expressed by DZone contributors are their own.