Prioritizing User Stories
December 30, 2017
An alternative to making time-based road maps is simply dividing user stories and epics into priorities.
Most companies use a three-bucket model, which sorts features into near-term (things to be completed in the next month or so), mid-term (this year or next year), and long-term (eventually).
How to prioritize
First of all, prioritization is extremely important and shouldn’t stop with user stories. You should be prioritizing initiatives, epics and other tasks that fall under your responsibility as a PM.
The actual feature is not the deciding factor in whether it’s prioritized or not. In fact, there are other external factors that play into the decision.
There are three quick methods you can use to prioritize user stories, epics, and more.
Assumption testing
Each one of your features is based on an assumption. Your highest-priority feature is the one based on the riskiest assumption.
In order to find it, analyze each one and identify the assumption behind it. Assign each feature a Risk Score from 1 to 10 (with 10 being riskiest).
Then score each one with an Important Score, again from 1 to 10 (10 being the most important).
Add the values together, and start from the feature that has the highest value.
This works for smaller user stories within an epic.
The BUCk Method
The Buck Method asks you to rate each feature based on the following three criteria:
- Business benefits
- User benefits
- Cost
Give each one a value from 1 to 10, with 10 being the highest value (or highest cost). Subtract cost from benefits to get each feature’s score.
This can help you sort features, but it can be hard to judge the value of benefits and costs on a 10-point scale.
The Moscow Method
This method asks you to categorize features into “Must,” “Could,” “Should,” and “Would.”
To decide, ask yourself: “What’s the worst thing that could happen if we don’t build this feature?”
These will help you to identify your “Must” features.
“Should” features are second in priority. They’re things that you should make, but won’t have such a huge effect if they’re not finished.
“Could” features are things that you are able to build, but don’t necessarily need now.
“Would” features are things that you would build if you had the right resources or timing.
If another, lesser feature is necessary to complete a “Must” feature, than the lesser feature is also a “Must.”
Keep in mind
These three frameworks are extremely helpful to divide up your tasks.
However, you can’t rely solely on them to help you.
Other external factors, like the market, competitors, other teams, and new technology can have a huge effect on your priorities.
These methods are not the “be-all end-all” of prioritization.
A final thought: Some of the biggest products today were created by companies that allow risk-taking. If you can afford it, sometimes you can throw reasoning out the window and take a risk.