No matter the kind of prioritization, there are many factors involved. Here are 5 of them.
5 Prioritization Factors
Prioritization is a distinctly subjective endeavor and should be undertaken with a lot of discussions, arguments and analysis. There is nothing simple about it.
With those thoughts as our backdrop, there are additional factors to take into account when prioritizing Stories. These factors supplement and modify the prioritization that arises from the Rule of 3 Prioritization Strategies in our earlier blog.
Underlying all prioritizations is the imperative to meet the Release Goal, if the Team has one. With that imperative in mind, each of these 5 factors is important at one time or another:
1. Stories with Business Value
There are many types of Stories that provide Business Value:
- Stories that provide Capabilities/Features for a system
- Bug fixes or Maintenance Stories in other systems
- Stories that help the sales or marketing people with materials, clients, etc.
- Analysis Stories involving the Product Owner and other Team Members working with Stakeholders and SMEs to find new Stories
It is the Product Owner’s responsibility to reconcile the different notions of business value that are owned by the different Stakeholders and decide which is most important – thus allowing final prioritization of the Stories.
It is important to keep in mind, one of the major issues in prioritizing Stories is how much effort will be used to mitigate the production of Technical Debt. Discussions about Prioritization often include comments like ‘“I want this one if it’s not too much effort.” Comments like these can become an evil pressure to cut corners and produce Technical Debt. If comments like these are said, they need to be discussed and agreed to.
2. Architecturally Significant Stories
Architecturally Significant Stories are Stories that reflect important decisions, not just boxes and arrows and high-level design, that have been made about how the software will be built. Typically, the Product Owner needs help from the Team to determine this sort of prioritization.
Architectural decisions should be made only in the context of doing actual work. That is, the Team does an actual Story with Business Value that forces it to make architectural decisions. Often, there are a number of Stories that all rely on the same underlying architectural decision. Whichever one the Team does first will cause the architectural decision to be made, so this Story is the Architecturally Significant one. This Story will be more Intrinsically Difficult and thus take more Ideal Effort than the ones that follow, so its size may need to be changed to reflect this.
There is always a balance between prioritizing purely on Business Value and prioritizing based on Architectural Significance. The Team is usually doing both types throughout the project, with the balance shifting from architecture-heavy Sprints to business-value-heavy Sprints as the Team moves through a release. Early Sprints in a release often put together a ‘walking skeleton’ (demonstrating the architectural decisions in running code) based on doing Architecturally Significant Stories, and the later Sprints focus on adding Business Value by adding “meat on the bones.”
3. Dependencies
One of the more interesting, and contentious, prioritization issues is the issue of dependencies. These dependencies come in two types:
- Feature Dependencies: The Team must develop a feature (or part of a feature) in order to develop another part (possibly of another feature). Sometimes this dependency is technical, sometimes it is architectural, and sometimes it is because the feature will be easier to review if delivered in this order.
- Technical Dependencies: The Team may see dependencies on some Chores, such as cleaning up code or improving the environment. These dependencies are less obvious and harder to see. They are often thought of as overhead, and the Product Owner has no real reason to want to do them. But the Team needs them Done in order to be able to produce the Business Value Stories the Product Owner wants.
If everything was perfect, the Product Owner would just take all these Stories and place them in the Backlog so that the dependency goes away by doing them in the appropriate order. This can usually be accomplished for the Feature Dependencies, as they are easier to see.
Unfortunately, things are not always perfect when thinking about the Chores. Remember that the Team does Chores primarily to maintain its Capacity going into the future, not because the Team wants “pretty code,” so this prioritization can get quite contentious.
4. People Availability
It may be obvious that sometimes the work can only be Done if specific people are available, but Teams usually don’t prioritize on this basis. Typically, Teams will try to get some work Done and then are stymied because people aren’t available, resulting in an impediment.
Usually, though, it’s a result of bad planning, not an actual impediment. People can be unexpectedly absent, which is an impediment, but Teams need to do more thinking about people’s availability when they prioritize.
5. PlaceHolder Stories
Sometimes we prioritize Stories that really have no content yet, just so we can reserve their effort for later. These Stories are for managing the known/unknowns and are called PlaceHolder Stories. One of the most common types of PlaceHolder Stories is the “Bug to be Named Later” Story, which simply reserves some StoryPoints to be used to fix bugs that the Team will be obligated to fix during the Sprint. PlaceHolders can be used for other reasons, as well. For example, the Team may say “Let’s put a 16 StoryPoint Story in here to hold effort we’ll use on support for the sales team this Sprint.”
Your Team’s prioritization is your Team’s prioritization. It’s up to your Team and your Product Owner to consider these 5 factors.
Interested in learning more? We’ve got training for that.
As Always, Stay Agile.