Prioritizing User Stories (User Stories 101: Part 5 of 5)

on August 5, 2014

Over this series in user stories, we’ve gone through how to identify users, how to lay out their needs, how to document them into stories, and how to put additional detail around those requirements. Now we need to answer the tough question: what do we actually do first?

Typically, we always seek the easiest, highest value items to work on next. To get there, though, we still need to determine what’s easy and what’s valuable.

Valuing Stories

User stories 101

For every story, we think through the following:

  • How desirable is this story to the core user group?
  • How does this story impact overall cost?
  • How important is this story in relation to other stories?

Each story then gets assigned a relative value to identify how important it is compared to others. We like the ‘MOSCOW’ method for identifying business value and priority. It’s easy enough:

**M**ust have, **S**hould have, **C**ould have, **W**ant to have

Every story card we write ends up with a relative value assigned to it by our product owner. Or, we might go more in depth using a system like the Kano model.

Another exercise to try is story shopping. We can assign a baseline value to each story (possibly from our initial estimates) and allow our client/product owner to “shop” for them with a fictitious amount of money. Of course, we ensure there’s more points on the table than the client has in terms of fake money – so, preference and choice emerges to help complete the exercise. It’s subtle, but it quickly shows us what we need to be focusing on and what items can wait for later.

Estimating Stories

While a product owner is evaluating the relative business value of our stories, our developers should be reviewing them to discuss the potential time (and thus, cost) each story will take. This figure can be incredibly important when making the decision of business value: a story that will take two weeks might be less desirable than one that takes two days. The only way to know is to confirm with our development team.

Like writing the actual stories, our team needs a common language in order to establish the recommended cost of each story. That language should allow us to:

  • Change our mind when we have new information about a story
  • Plan for epics and smaller stories
  • Not spend much time estimating
  • Provide useful information about our work and the time remaining
  • Take imprecision of estimation into account
  • Quickly plan releases

To that end, our team prefers to use abstracted points rather than estimating in hours. They represent no real unit of time, but are a currency the entire team can comprehend.

It’s a good idea to use pre-defined values like the modified Fibonacci sequence: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 80. A logarithmic scale like that reminds us that point precision decreases as story sizes increase. To keep things simple, we sometimes use a difficulty scale, where 4 points represents an extremely complex story, whereas 2 points is half as difficult.

That last bit is important: remember that an estimate is really a “size”, not a true time estimate. To that end, it’s always best to think of how stories relate to one another in terms of relative difficult and assign that point value accordingly.

Estimating Meetings

Here’s the workflow for how to convey user stories to a development team, clarify their needs and then produce an estimate.

  1. Gather the team (both the customer team and developer team) and share the stories.
  2. The customer team reads a story to the developers.
  3. The developers ask questions and the customer clarifies. (Remember: take good testing notes!)
  4. Each developer should write a story point estimate down for each story without showing the other developers.
  5. At the end of this process, each developer should share the story estimates with each other.  These will all differ.
  6. The high and low estimators will need to explain their decisions and discuss for clarity with the group.
  7. From there, the group should converge on one point number estimate for each story.

This process is often called “Planning Poker”, since it involves a sort of card game like estimate reveal.

Once our team fully understands the list of relevant stories, we put those size estimates on each one. We organize our cards into a digital system like Trello and allow our client to prioritize the stories at will. We make recommendations on how to address the right order of a stories, but ultimately the client is responsible for choosing what we work on in order.

agile trello board

An example agile board built in Trello.

Once we’re into a system like this, we’ve now got a prioritized, estimated and well-organized backlog of work that our team can start chipping away at.

The goal here, again, is not to keep things set in stone; we gathered and learned enough to get going. The list of stories can always be polished, pruned and expounded upon. In fact, we welcome this.

Our team at Centresource regularly  trains clients on how to write stories and manage their own product roadmap. We would love to hear any questions or comments you may have on the subject, or if you’d like to learn more, setup a time to chat.

 

Editor’s Note: This series was originally drafted by Jon Arnold, but was not published until after he left Centresource for his next adventure as Product Manager at Taonii. You can find Jon on Twitter @jonarnold.