How to Prioritize User Stories

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Askshutterstock_178631474

His face was stern, and his voice had an air of seriousness, “I don’t think you quite understand.  In our business, everything is priority.”

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.

“15% of our revenue came from Paypal in the last version of this product, so it stands to reason that 15% of our revenue will continue to come from Paypal.  On the other hand, only 5% of our revenue came from ACH debit, so the Paypal functionality will be prioritized higher than the ACH functionality.”

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:

The old platform costs 10c per transaction, and the new platform costs 7c per transaction.  Moving the functionality to the new platform will save us 30% per transaction, and we do over 1 million transactions per month.

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:

The state fines us a surcharge depending on how accurate our claims payment processing is.  This functionality will reduce claims errors by 30%, reducing the risk of non-compliance.

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.

There was an issue loading your timed LeadBox™. Please check plugin settings.