How to Prioritize User Stories (and Build the Right Features)

So you’ve worked with your users and other parties invested in your project to capture a big pile of user stories for your new web or mobile app – but we can’t, and shouldn’t, build everything people ask for. Money doesn’t grow on trees, and certainly some items are higher value than others.

We need to prioritize. We need to talk about and understand which of those stories are the highest value and critical to success, and build those items first. It’s a critical step of the technology consulting process, and here’s how to do it.

Prioritization Methods

There are a couple of prioritization methods you can use. First is the MoSCoW method, wherein each user story is prioritized as one of the following:

• Must Have: the first version of this product absolutely requires this functionality – it is critical to the app’s success.
• Should Have: it would be ideal if the first version of this application has this functionality, but it isn’t absolutely required. They may be as important, but not as time-critical, as Must-Haves.
• Could Have: the user story has value and is desirable, but ultimately is not necessary.
• Won’t Have: the user story is understood to be amongst the least-critical or lowest value.

Alternatively, you can also use a simple numerical (1-3) prioritization method, following similar criteria:

1. Stories classed as 1s are critical and must be delivered.
2. Stories classed as 2s have value, but if they have to be cut due to time or budget, they can be.
3. Stories classed as 3s are either lower priority or need to be further unpacked/discussed.

Ultimately, the prioritization method you choose is up to you. They both work. Understanding the priority of each user story will help in a few scenarios going forward, including:

Estimation. If you’re doing discovery work to provide scope to an agency or internal team for timeline/costing, they can estimate based on the groupings (e.g. “Here is the effort / cost / timeline for the minimum viable product or MVP of your application– defined as all user stories classed as M or 1” or “Here is the effort / cost / timeline to deliver all 1s and 2s (or Ms and Ss) as requested”), as well as;

Prioritization of work. Prioritizing the cards helps the development team prioritize what work to do and when, when the actual production cycle begins. The team won’t be working on low-value items.

The User Story Prioritization Process

Pick a prioritization method and write down the definitions for the ranks on a whiteboard so the rest of the group in the room have a reference point. Explain the method to the group.

Then, organize your pile of user story flashcards into a neat stack. Hold up the first card, read it out loud, and ask the group to “rank” the user story.

If you’re using the numerical prioritization method, each member of the group can just hold up fingers (1, 2, or 3 fingers). If you’re using the MoSCoW method, it’s helpful for each participant to have an M flashcard, an S flashcard, and so forth so they can just hold up the appropriate rank card (kind of like judges in the dunk contest).

Sometimes the entire group will rank a user story the same – i.e. immediate consensus that a story is a 1, or an M. In that instance, it’s easy. Write down the rank in the corner of the card, and start a new pile for that priority level. Our free user story flashcard template, which you can print off, has a handy little spot to mark each story’s priority.

More often, however, members of the group will have differing opinions on how important or valuable a certain user story is. In this instance, as the moderator of the exercise, it’s up to you to ask the right questions and/or steer the group to help reach a consensus on that story’s priority. If you’re an expert in application delivery, you might be able to weigh in with an opinion as well either around value to the identified user or potential effort level (e.g. this is likely low-effort but mid-high value, so let’s make it a 1).

Remember though: just like in the user story generation phase, the priority of these cards is not written in stone. The priorities can and should be flexible – agile, even – as the project moves forward and more information is learned.

Continue in this fashion: hold up the card, read it out loud, ask for a ranking from the group, reach a consensus, write down the agreed upon priority level on the card, and place it in the “prioritized” stacks (it’s recommended to have a separate stack of cards for each priority level). Soon enough, your huge pile of unprioritized user stories will be a prioritized, tidy, and neat collection of user stories.

It’s important to remember that the conversations that happen are important. These instances – when participants are questioning priority level, or asking a story author what vision they have in their head for how something might work – should be captured, either in an audio recording or by someone taking dedicated and detailed meeting notes.

Finally, using multiple prioritization methods to narrow your focus (and budget) can be useful in gaining consensus among your team as you move into application development. By using the 2×2 Matrix, you can map out your user stories by comparing the effort required to introduce specific features to your application against the value its inclusion brings to your organization and end users. You can read more about the 2×2 Matrix here.

Transferring User Stories to Digital Format

Unless you want to present a giant stack of cards to your internal team, your boss, or a digital agency, you’re going to want to transfer the user story cards to a digital format. We recommend a simple spreadsheet or table with a Priority column (MSCW or 1/2/3) in the far left column, an ID column using numerical sequencing beside that (e.g. US001, US002, etc. – trust me, the numerical sequencing will come in handy for future stages like user journeys, QA/UA testing and the like), the story in the column beside that, and lastly a blank column called Acceptance Criteria beside that.

If you want to save some time, you can just download the spreadsheet we use for digitizing user stories at the bottom of this article.

What Happens Next?

If you followed these steps, you’ll have a valuable and exhaustive list of prioritized user stories that are a macro-level set of functional (and non-functional) requirements for your application. In conjunction with the project brief and user personas that preceded user stories, you’re starting to get a pretty good understanding of the application – you’re discovering it piece by piece like a tried-and-true technology consultant.

However, at this stage the user stories we authored and ranked don’t have quite enough detail to effectively begin to design, build out, and test. So, before we can do that, we need to learn how to have some conversations and unpack acceptance criteria for each user story.