It's Time to Organize Your User Stories

If everything is important, then nothing is important.

Rating ALL of your user stories as “high priority” is a common issue when gathering requirements for a project. However, as soon as you start thinking about “who” is going to get the benefit (value) of Feature A, “what” is Feature A (a detailed description), and “why” you’re building Feature A (the benefit or issue being addressed), then you realize that what you thought was the next “big thing” isn’t actually isn’t as important as you thought.

There are some prioritization methods that can be helpful, but before diving into them, I would like to share some tips on writing useful and clear user stories. And guess what; it starts with the USER:

• U — Unique: a clear statement describing the benefit and how it’s different from other user stories.
• S — Simple: a single sentence that can be readily understood.
• E — Explicit: other user stories can’t overlap its functionality.
• R — Realistic: an idea that can be achieved / implemented.

Let’s review some examples:

As an Administrator (who), I want to be able to manage my system user accounts (what), so I can address their needs easily (why).

As a Customer (who), I want to be able to add products to my wish list (what), so I can quickly purchase them when needed (why).

Once your backlog is filled with stories, it’s time to set priorities.

Prioritization by Value and Complexity.

All user stories are not equally important. You have to be very aggressive in defining which stories provide more value to your business and must be part of your minimum viable product.

Personally, I like a combination of the MoSCoW method and the complexity matrix. Using the MoSCoW method, each user story is prioritized as one of the following:

• M — Must have: Also known as the minimum viable product. This category is for stories that are critical for the success of the project.
• S — Should have: Important stories to be included (if possible), but not mandatory for the success of the project.
• C — Could have: Also known as “nice to have”. They are valuable stories; desirable but not necessary.
• W — Won’t have: Lowest value stories. They have potential value and can be implemented in a future release.

Now, let’s add a dimension to our backlog: complexity. By adding complexity, the product owner is able to have a high level idea of the effort required to estimate it. It’s a good strategy to include complex stories in an earlier sprint. By tackling them early, you can test and collect feedback in a timely manner.

The possible values for complexity are: High, Medium, and Low. It’s also very useful to provide a range of story points (from X to Z) to each category.

This is how our backlog looks: