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

Focused delivery of value

Isn’t that what it’s all about? I was writing something else today about aligning resources and part of what I wrote was “focus resources on the high value deliverables for quick impact and realization of value”. Anything that gets in the way of this is a negative and removes value from o software development project. It seems so basic. In a nut shell this one sentence describes the goal of using agile project management methods.

Focused delivery of value