This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask
If I had a dollar for every time I heard this, I would be a very wealthy man. Yes, everything is priority. Everything is always priority because you have a large group of stakeholders and they all want their stuff first, thus everything is priority.
Realistically, you can not get everything done all at the same time, so even though “everything is priority”, some things will come first, and some things will come last. A softer word for priority is “order”, but in this article I am going to show you how to prioritize user stories.
Option 1: Prioritize by Knowledge Value
At the beginning of a project, what you don’t know might hurt you. Removing the unknowns is a huge opportunity to positively impact the health of the project over time. In order to prioritize on knowledge value, we have to be willing to admit we don’t have all the answers to the unknowns. After we do that, we can prioritize some of the “knowledge value” items on the backlog, such as spikes and prototypes.
Option 2: Prioritize by Increased Revenue
This one is always a clear winner, but is heavily dependent on the sophistication of the product owner to be able to articulate the ROI associated with a feature or user story. Therefore, this needs to be one of the items thought about when prioritizing. An example of this would be payment options.
Option 3: Prioritize by Reduced Cost
This is another one that is easy to articulate and easy to defend, but requires some research and number crunching to have a sound basis. Cost reduction or reduction of “Total Cost of Ownership” is usually one of the driving forces behind new projects. An example of cost reduction would be changing platforms:
Option 4: Prioritize by Reduced Risk
There are all kinds of project risks to keep in mind: Technical Risk (can this be done?), Social Risk (can these people do it), and Execution Risk (will the marketplace accept this?). Items in your backlog that can point to a reduced risk can be prioritized according to the magnitude and likelihood of the risk itself. Here is an example:
Its always a guessing game
Prioritization is always a guessing game, and you have to find the balance between getting a perfect priority and being flexible enough to let the work emerge. Don’t ever expect to get a perfect priority. Some stakeholders will always be unsatisfied with how it was done. As long as you have a framework to guide your thinking, you can defend the choices when asked.
