Sunday, January 25, 2009

User Stories and And…

In an earlier post I talked about the three elements of a good user story, who, what, and why. The word “and” does not belong in one of these elements. If you are not familiar with the three elements of a user story, read this post “User Stories and the 3 things that make them complete” before proceeding.

Check out this user story, can you spot the potential problem?

Daytime and nighttime customers want to add products to a shopping cart and checkout so they can select and purchase products.

The example is an awkward and big user story that covers a lot of functionality. The “what” section covers multiple pieces of functionality, the word “and” is your indication that the story is too big. This user story may be so big that the functionality may not be completed in a single sprint.

The example user story needs to be two separate user stories to show a separate user goal “what” per user story.

  1. As a customer I want to add products to a shopping cart so I have a container for the products I want.
  2. As a customer I want to check out so I can purchase products I want.

Each of the above user stories is a viable user story that can be ranked and implanted independent of the other. So look out for the word “and” in the “what” section of a user story as a warning that the user story is too broad.


Monday, January 5, 2009

User Story Prioritization - Part 1

Prioritizing the product backlog is an important step to make sure the agile software development team is focused on the correct set of user stories. The initial product backlog can consist from a few user stories to several hundred. Trying to prioritize several hundred user stories is a huge task that can be simplified by using MoSCoW ratings.

MoSCoW ratings defined:
M - MUST have this feature – the product will fail to meet needs without this
S - SHOULD have this feature – an important feature that has an acceptable work around
C - COULD have this feature – wish list item
W - WON'T have this feature at this time – might move to Must, Could or Should in the future.

Product owners and business folks seem to understand this approach and find it easier to deal with a large product backlog by using MoSCoW ratings.

Once a user story is MoSCoW rated only the Must user stories need to be prioritized. The rest of the user stories are not MoSCoW rated high enough to warrant the effort to do a numerical prioritization. That said, MoSCoW ratings on user stories can change over time, what was once a Must can become a Could or Should and so on…

Assigning a user story a MoSCoW rating is a quick and dirty way to quickly narrow down on what is important to deliver to make the product a success.