Prioritizing Across the Themes in Your Product
This post originally appeared on the PivotalTracker blog.
Prioritizing a single set of work for your team can be hard; prioritizing work across multiple sets of work can be nearly impossible.
As a product matures, product managers often find themselves contending with multiple themes of work in their product backlog. This can happen as a product begins to serve different personas, or even begins to find itself in different markets. As a result, product managers often find themselves having to shape each release to appease each type of persona.
Differentiating between themes and epics
A theme is a group of related stories that you’ve identified for your product. While at first this may sound the same as an epic, they’re actually two different concepts. While epics and themes are both comprised of sets of related stories in your product backlog, they differ in one key aspect: An epic will provide no significant business value to your product until all stories in that epic have been released; a theme, on the other hand, can be partially released and still provide some value. In fact, each story in a theme is capable of standing on its own and still providing value.
Let’s look at an example. Imagine that you’re a product manager for a product that helps companies track their users’ engagements with their website. You’ve just designed a feature for your product that tracks how many times a given user visits a website over a certain time period. This feature will help companies understand how many times a user is likely to return to the site before they become a paying a customer.
With the help of your team, you’ve created an epic comprised of four stories that represent this feature:
Tag a new visitor when they visit the website
Identify and log a returning visitor when they return to the site
Analyze each user’s engagements with the website over a given time period
Report the outcome of this analysis to product managers in an easily digestible way
Representing this feature as a series of smaller stories will make those stories easier for your team to understand and develop. However, while each story may be developed and delivered individually, these stories will provide no actual business value until the entire epic has been delivered. For example, having the ability to track a user’s visits and analyze the patterns of those visits will provide no value until the results of that analysis can be surfaced to the product’s end users in the form of a report.
Recognizing themes in your product
Compare this to a theme that may still consist of related stories, but stories that are not *so* closely related that they can’t provide value by themselves. As an example, let’s once again imagine that you’re the product manager of the product described above. While your users have been generally pleased with the value your product provides, many have complained about various performance problems with the product. For example, maybe your product’s reports can be slow to generate and even slower to respond. Or maybe the tracking code that your product provides for your users’ websites has impacted those websites’ performance. This feedback has led you to create a theme about improving performance that you’d like to tackle in future a release of your product.
With your team, you’ve created an initial cut of stories that will comprise this theme:
Improve the rendering performance of the Visitor Behavior report
Improve the filtering performance of the Visitor Behavior report
Reduce the performance impact of the tracking code on customer websites
Increase the frequency of visitor behavior aggregation from nightly to hourly
While these stories *are* related, there is a critical difference between them and the stories in our epic example: any of these stories could be released independently and still provide some value to your users. For example, while your users may prefer that you improve both the rendering and filtering performance of the Visitor Behavior report, they’ll still appreciate you improving at least the rendering performance of this report. And while reducing the performance impact of your product’s tracking code on your users’ website would no doubt be a welcome improvement, you would never consider withholding the performance improvements to the Visitors Behavior report if the tracking code performance wasn’t finished. And herein lies the key trait of a theme: while the value of the stories that comprise a theme may increase as more stories in that theme are delivered, those stories are still perfectly capable of delivering value on their own.
Prioritizing the themes across your product
Now that you understand what themes are, let’s talk about how we can prioritize them.
The challenge of prioritizing work across multiple themes is ensuring that all themes are represented in each release. While you occasionally may want to favor a certain theme above others in the interest of creating a more coherent release, in general you’ll want a well-balanced release that appeals to all of your user personas. But how do you do this?
First start by drawing a series of concentric circles, each of which represents an upcoming release. Your nearest release should be in the center, with further releases progressing towards the outer rings of the circle. You can even consider the region outside of the largest circle as future releases that haven’t been planned yet.
Next, for each theme in your product, draw one line from the center of the chart to the outer edge of the largest circle. For example, if you’ve identified five themes in your product, then you would have five lines evenly spaced around the series of circles.
Finally, begin working through your product backlog by placing each story on the appropriate theme. In general, each story should not belong to more than one theme. If you have a story that seems to belong to more than one theme, that may be a sign that either the story is too large and should be split, or that two of your themes are closely related and may need to be combined. In addition, don’t be surprised if some of your stories don’t seem to belong to any theme. This can often be true for stories that represent a specific request from a customer and don’t really match the rest of your product. In these cases, simply place any stories that don’t match a certain theme in the space between the theme lines on the chart.
Time to plan your releases
Now that you have each of your stories assigned to themes, it’s time to begin planning your release. To do this, you can begin by spreading your stories out across your upcoming releases according to your team’s expected capacity.
You can use this chart to understand how balanced each of your releases are. For example, do you have a certain release that seems overly biased towards a certain theme at the expense of others? Or do you have certain complementary stories identified for different releases that would make a greater impact if they were delivered together?
While this exercise can be valuable, you likely won’t need to repeat it when planning every release. However, periodically plotting your releases can reveal insights into what themes are becoming dominant in each release and what steps you can take to restore balance and deliver a release that will appeal to all of your product’s users.