Why User Stories?

As a ... developer

I want ... well written requirements with clear acceptance criteria

So that ... I understand the functionality I am being asked to build, I understand the value of building it & I know when I am finished building it.

When an organisation switches to using agile methodologies, one of the most often asked questions by analysts and developers is “Why do we have to write user stories for everything?”  I’m sure that nothing irks a business analyst more than having to convert their beautifully crafted requirements document into a backlog of user stories.

Even when teams are in the flow of using stories as currency and have accepted that all functionality needs to be specified in user story format,  the tendency to disregard or misinterpret the INVEST principles is ubiquitous. Having a ‘bad’ user story can result in confusion, waste and inefficiency.

In general you’ll find scrum masters espousing the INVEST principles and the simple “as a, I want, so that” format. Story writers will often try to stick to these principles but through inexperience or lack of understanding will omit important elements or not fully understand WHY a principle is important.

In this article I try to impart some of my experience of writing and using user stories to highlight WHY they are a valuable part of the agile process and also try to put some clarity around the INVEST principles.

Let’s start with the basic format.  

As a ...

I want ...

So that ...

This is a very basic template, but it’s basic for a reason. Keep things simple, don’t overcomplicate the requirement. A user story describes a basic unit of functionality. Sticking to this format is not being pedantic; there are very valuable reasons for each section

Why specify the "As a ..."?

Developers need to know who will use this piece of functionality. By specifying the user, we remove doubt. This eliminates those irritating, post-development discussions such as "It was supposed to work for user type X only".

Smells:

• If we don't know who we are building this story for, i.e. the end user, then why are we building it? Is this functionality really required? As a scrum master if my product owner cannot answer this question then I will challenge whether he can save the project time and money by omitting it.
• Multiple user types are specified. To keep user stories small and to avoid complexity it is advisable to have only one user type per story UNLESS the functionality is the exact same for each user. If the functionality is the same, then you can simplify by stating “As a .. user of the system” or something similarly generic that suits your model. When I see the word “AND” in the “As a ..” section it automatically sets an alarm bell off in my head.
• “As a Product Owner” is not a valid user type for this section. We should not be using development teams to build features from a product owner’s wish list unless they are justifiably needed by end users. Better uses here would be “As a logged in user”, “As a guest user”, “As a system administrator” etc. etc.

Why specify the "I want ..."?

This is the actual requirement. What do you want to do?

Smells:

• “I want this AND that”. Try to avoid the use of the word "AND". If you need to say "AND" then question whether you should break this up into multiple stories. Is the “AND” bit another unit of functionality?
• Verbose descriptions are not needed here. This should be a succinct statement of what the requirement is. If you cannot provide a succinct description then you may need to think about what the requirement and clarify the need that is to be satisfied.

Why specify the "So that ..."?

Why are we building this piece of functionality? If we cannot capture the value then why build the functionality? What need is satisfied if a development team builds the feature you are requesting?

Particularly in a team with limited resources this is the most important part of the story. This should help product owners prioritize requirements.

Smell:

·         If you find you cannot fill in the "So that" section, then you should seriously challenge the story and whether or not it should be worked on.

Additionally:

“This story is done when ...”

A user story should have clearly defined acceptance criteria. This enables the story to be tested and enables a developer to know when to finish developing. It’s ok to flush out these acceptance criteria as part of the “discussion”. Remember, a story is a promise for a conversation, and every story should have a conversation between the developer and the requestor.

Scenarios

These are very useful for testing. Specific journeys such as:
“go to page x, enter username/ password, click login, click accept disclaimer, verify text exists on next page, verify new feature exists etc.”

As these scenarios are of specific interest to the tester of the story, it is often best for a tester to work on flushing out these scenarios in collaboration with the product owner and also maybe the developer.

 

Finally

• A brain-dump of everything you know about a requirement does not a good story make! It only serves to reduce the clarity of the requirement.
• There is a feeling that writing a requirement in user story format takes more time, it doesn't. It takes more thought!
• Sometimes it may feel artificial to force a requirement into user story format. If it does, then talk it through with someone and see if they can phrase it better and verbalize the value more clearly. Persisting with the format will result in clarity of requirements and will highlight the value of the work we are delivering.

The INVEST principles

In my experience, a well-written user story follows the INVEST model. You don't need to tick all the boxes, but the more the better!

“Independent, Negotiable, Valuable, Estimable, Small, Testable.“

• Independent - One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult.
• Negotiable - A user story is negotiable. The "Card" of the story is just a short description of the story which does not include all the details. The details are worked out during the "Conversation" phase. A "Card" with too much detail on it actually limits conversation with the customer.
• Valuable - Each story has to be of value to the customer. A story should deliver value independently of all other stories.
• Estimable - The developers need to be able to estimate a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of clarity in the requirement or lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).
• Small - A good story should be small in effort, allowing the team to complete many units of functionality in a given iteration
• Testable - A story needs to be testable for the "Confirmation" to take place. If you can't test it then you will never know when you are done.

To sum up, I recommend following the INVEST principles and I also think that the basic user story template is so crucial to a simple, easily digestible user story. Writing user stories shouldn’t be viewed as chore or an additional tax on a project, but an absolute necessity for a development team to deliver successfully