Writing Correct User Stories

There are many things that are cools about agile, but user stories are probably one of the most mind boggling. They are a very powerful exercise to understand more about the value the team is suppose to deliver and how a product or feature is a mere vehicle for that value.

While this is no exact science, there are a few best practices and guidance about how to write correct user stories.

The Format

As a <user type>
I want this <functionality>
So that I get this <benefit>

A user story should be very clear in terms of what needs to be achieved, for whom and why. For everything the team will build there will be an end user. For every functionality there will be a benefit.A user story should be very clear in terms of what needs to be achieved, for whom and why. For everything the team will build there will be an end user. For every functionality there will be a benefit.

The 3 Cs

Ron Jeffries introduced this concept in 2001. A user story must fit on a card, must trigger a conversations and must have a clear confirmation that it’s done.

Card – a user story should be simple and concise enough to be written on a card (post it or sticky note). Not only will it be simple to read and understand but it will also radiate (information radiators are how information is displayed in agile projects). You can put it on the wall, place it on a Kanban board, touch it, feel it.

Conversation – not much can be written on a piece of paper that’s why the card is only a placeholder for a conversation. Of course, if written documentation is need, it will be generated and provided, but generally people prefer an open discussion about what needs to be built and delivered. Besides, that how you get the aha moment about what people really want.

Confirmation – this who are working on a user story must have the confirmation that their work is going to be accepted by the client. The confirmation is about what would make the user story done (definition of done) and accepted by those who requested it.

INVEST

The INVEST acronym was created by Bill Wake as a reminder of the characteristics of a good quality user story.

I – Independent one from the other. Stories should be independent enough to implement them independently and also to move them, one by one, when the backlog is reprioritised.

N – Negotiable means the story is not a firm contract and it should allow interpretations and negotiations. From these negotiations, the best possible implementation should emerge. 

V – Valuable because otherwise there is no point in doing them. This is the value that the customer receives once the user story is delivered.

E – Estimable means the story should be possible and easy to estimate by allocating it a number of story points.

S – Small means it requires less work and consequently it will be delivered faster and spend less time open (as Work in Progress) and the value will be achieved faster.

T – Testable criteria means whatever is considered as acceptable criteria should be easy to test and conclude whether the story is accepted or not.

Example of a user story

As a beginner in agile,
I want to understand how to write user stories
So that I deliver more value to my customers.

Definition of Done
I want to be able to write my own stories
I want to be able to spot a poorly written user story
© Rolf Consulting