5 tips for better user stories

After an initial romance with use cases, the agile community embraced user stories as its de facto standard for documenting requirements. You have probably seen them a lot by now and maybe even wrote a few:

As a <user type>
I want <action>
So that <benefit>

To make them more versatile, Mike Cohn introduced two additional terms: epics and themes. Epics refer to big user stories, that would probably take a long time (weeks or months) to develop. Themes designate related user stories, for example you could have a “reports” theme.

Sometimes this format is not enough, so the teams I work with often come up with creative additions. Here are my top five:

1. Use personas

A lot of people went bankrupt during the dot com bubble because they believed the mantra build it and they will come. Our industry has learned a lot since then and we have started shifting our focus from “the system” to “the user”.

What I see quite often with user stories is that they start with As a user... This is often a sign that the team did not think about the target user for that particular story. What often helps are personas.

Personas are a technique originating in the User-Centered Design community. It tries to identify a few distinct groups within the user base. Team start by defining the 4-6 most representative types of users and then keep them in mind when creating the user stories. This increases the chances that the user stories will satisfy actual user needs.

Below you can see an example persona from the I TAKE Unconference, one of our projects. For each of the target attendees, we came up with a name, a job title and why they would come to the conference.

Paul(Programmer): Seeing how other programmers work, experimenting new 
techniques in a learning environment, learning new techniques, being
more productive.

So instead of As a user..., we can now say As Paul... when we think about new features.

2. Don’t be a slave to the format

Sure, the original template is As a... I want... So that..., but that does not mean we should turn it into a rule cast in stone. When you start seeing stories like As a developer I want to install Jenkins So that I can run automated tests you know you have a problem. Experiment with the format, keeping in mind its three components:

• What are we building? (I want…)
• Who are we building it for? (As a…)
• Why are we building it? (So that…)

Let’s take the following example:

As a conference junkie
I want to see what is different about I TAKE
So that I can decide which conference to attend at the end of May

I’m pretty sure Mike Cohn won’t have any objections if he saw it written this way:

Highlight what is different about I TAKE
Persona: Frank (conference "junkie")
Why: To decide which conference to attend at the end of May

3. Limit their size

When doing Scrum, one of the reasons teams don’t finish what they committed to for the current Sprint is the fact that the stories were too big and in the last day of the Sprint each one is 99.999% done. Actually, there is no such thing as x% done. A story is either NOT STARTED, IN PROGRESS or DONE.

By limiting the size of each story that you select for the next period, you increase the odds of finishing it in time. My default rule of thumb is to cap story size at five ideal days.

4. Correlate with business goal

The Product Owner, Product Manager or Council of the Elders which decide the next important features, ideally do so starting from the business goals.

I was working recently with a team of senior managers trying to decide the development priorities for the following period. One hour passed and the efforts were fruitless, with everyone advocating their particular preference. So I asked: “What is the business goal for the next 3 months?”. Once we started discussing that, the priorities became much clearer for everyone involved and we finished selecting the next user stories quite rapidly.

Needless to say, in an open and collaborative culture, these goals then get shared with the team.

5. Add other information you need

The back of the sticky note/index card or the description field in your project tracking tool is the ideal candidate to store additional information about the user story. Some likely candidates:

• The personas we discussed above
• Acceptance criteria (small business focused test cases) or scenarios if you are doing BDD/ATDD
• Non functional requirements like Search must support 1.000 simultaneous users or Total time to find an element with the wizard must be < 1.2 seconds
• Mockups or wireframes produced by the UI/UX designer. My personal favorite is Balsamiq.

These are my five top tips for writing user stories. What about you? How do you write user stories? What other tips or techniques do you use?