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.

User Stories and And…

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.

User Story Prioritization - Part 1

User Stories and the 3 things that make them complete

A really good user story will have three things to make them useful and complete

• Who
• What
• Why
  

I’ve seen so many user stories that have the Who and What nailed, but they miss the Why. Adding the Why seems to be the hardest part, but it’s so useful for prioritization and for stakeholder understanding.


So what are these user story elements?

• Who = the primary actor. The Who can be generic like customer, user or specific such as specialized user of a system. The Who can also be a non user such as a server; I’ll give an example later.
• What = the action the primary actor wants to take.
• Why = the value or the reason the primary actor wants to do the action.
  

When writing user stories I’ll use standard phrases to ensure the completeness of the user stories

1. “As a” to identify the Who
2. “I want to” to identify the What
3. “So that” to identify the Why
   

So let’s write a few user stories as examples

1. As a customer (who) I want to add items to a shopping cart (what) so that I can purchase them (why)
2. As a server (who) I want to receive well formed xml (what) so that I can process XML without errors (why)

As I write this I found some proposals to switch the Who, What Why to Why, Who, What to provide the business value up front. It’s an interesting idea to try when you write your user stories.

User Stories and the 3 things that make them complete

Getting Started with Agile Project Management

I've recently read some discussions about how to get started with Agile Project Management. Its not hard to get started with Agile, however Agile project management is hard to sustain if you are not prepared for the issues that will arise. From personal experience there are a few things to tackle before adopting Agile Project Management. These ere education, training, finding a coach, and just getting started. The education part is pretty easy, there are some really good books that cover Agile Project Management and User Stories.

Books -I've read all of these Agile Project Management book and use them as a reference.

• Agile Project Management with Scrum


• Agile Estimating and Planning


• User Stories Applied

Certification - The Certified Scrum Master certification class is a great way to get some exposure to Scrum and learn about some common issues that beginners run into. Its even better to send several people on the team to the CSM class.

Coaching - Agile is hard, get an Agile Coach to guide you through the first project or at least the first few sprints. The value of the knowledge transfer and guidance will far outweigh the cost of the coach. The coach will know from experience what problems happen with new agile teams and can guide the team through the trouble spots

Just Get Started - I remember the very first step we took to adopt Agile Project Management. The development team was in a conference room with the product owner, we wrote 12 user stories and prioritized them. The simple step of getting requirements via user stories and prioritizing them into the product backlog was an eye opening experience for the team. At once the software development team understood what was important to the product owner and the product owner better understood what the software development team could do in the time period for the project. In the world of Agile this is a very simple step but it was the first crucial step to change the way the software development team interacted with the product owner. So, go read some books, get certified and take your first steps, its worth it.

Getting Started with Agile Project Management

Agile and User Interface Mockups

Some people will argue that user interface mockups smell of big planning and have no place in agile, I disagree. Let’s face it; it’s hard for a product owner to communicate to the software development team how a software product should look and work without pictures.

A product owner that has screen mockups to work with has a powerful tool to elaborate user stories. Pictures enhance collaboration and understanding by giving the software development team an alternate method of receiving software product requirements from the product owner.

From a QA perspective, the mockups serve as a guide for testing the user interface to ensure that the user interface is developed as requested by the product owner.

It gets tricky though when the user interface mockup illustrates product functionality covered by several user stories. The one easy way around this is to just add the user story number to the mockup and use themes.

Agile and User Interface Mockups