Prioritise user stories and produce more value sooner

By Nick Butler

Tags: Agile

Numbered lanes on running track for above. Prioritise user stories and get to the finish line faster.

The team at your Agile Project Kick-off have just finished User Story Mapping. Next step: prioritise user stories.

Get the Agile Project Kick-off Kit as a handy 39-page PDF. Based on this blog post series, it’s been revised and expanded, giving you the tools you need to get your project off to a successful start.

Buy the Kit

As a team, you’ll decide which of the stories deliver the most value, most quickly.

Next you’ll find the smallest collection of these stories that together will produce something your customers will find useful. What is the Minimum Viable Product (MVP) that will be valuable, and will let you gather valuable feedback from your customers?

You’ll then be ready to write the user stories for this MVP. These stories will guide the development of the first iteration of your product. You’ll be good to go.

This exercise further develops your user story map so, if you haven’t already, it’s worth reading our post on user story mapping first.

Prioritise user stories with personas

Your Pragmatic Personas help you start prioritising the user story map. You’ve already ranked your personas by priority and given each of them a different coloured dot.

Decide which stories mainly benefit one persona and stick that persona’s dot on those stories. Straight away you can see which stories offer the most to your most valued persona.

Prioritise user stories with MoSCoW and the MVP

Next we decide which stories we Must, Could, Should and Won’t do (MoSCoW for short).

If people resist the idea that there are some stories you Won’t do then the ‘W’ can stand for Would (you Would do them if the project miraculously found more time or money).

Those stories that mainly offer value to your top persona are good candidates, though they’re not invariably Musts.

A whiteboard outline of a user story map showing how you prioritise user stories. — *An outline of a user story map after the stories have been prioritised*

Stick up three horizontal strips of tape across the wall (the green dashes in the illustration above). Leave room between the strips. You’ll be grouping user story post-its into swim lanes between these lines.

Now move all the Musts above the top line of tape. While you’re at it, move all the other stories below the line, grouping them into Shoulds, Coulds and Won’ts. You can then arrange the user stories under the epic they help achieve.

You’ve now got your stories ranked in priority from top to bottom. At the top, the collection of Musts is your Minimum Viable Product. It’s the first thing you’ll be working on (though not the only thing).

Get the team to walk along the map and make sure these Musts are all and only the stories needed to produce a cohesive, standalone product that lets customers complete enough of their goals that they’ll adopt your offering.

Why prioritise user stories?

The short answer is that it works.

It lets you identify the business value of each story, do the most valuable work first, deliver quickly in order to get feedback and then reprioritise the remaining work based on what you’ve learned. It also provides a starting point for the development team.

But you have to be brutal.

You need a ruthless focus on including only the minimum in your Minimum Viable Product. There’s a reason it’s not called the Smallish Viable Product. (If you want to learn about the science behind keeping the size to a minimum, read our blog post on How reducing your batch size reduces costs.)

That said, it’s hard to prioritise user stories. People want to keep everything in the Musts. They saw a benefit to the user when the story was suggested and it’s hard to set that aside.

So sometimes the facilitator needs to challenge the team. The critical question is whether the customer can still achieve their goal if you don’t complete a particular story.

Next steps

Next up on the discovery kick-off agenda is writing user stories. You’ll only create user stories for the Musts. This minimises the work you have to do before you start developing. The joy of Agile is that it’s a just-in-time process. You get to limit your work to what’s needed at that moment.

Capture the epics and all the user stories (you don’t need to capture the user tasks). The non-MVP stories go in backlog as a “stub”, a brief but meaningful label.

You may also want to take your story map further, especially for larger projects. Jeff Patton suggests socialising it with users and the business to ensure it’s complete and correct. You can check it covers exceptions, records dependencies, catches pain points and notes any technical complexities.

But if you finished now you’d have a starting point for your development. You may have challenged what people thought they needed and you’ll have a shared understanding of what’s important. Keep in mind that this understanding may change as you learn more, including any feedback you get on the MVP and later iterations.

While there are other techniques you can use to prioritise stories, this one is simple and speedy enough to complete as part of a Project Kick-off.