Scrum: Writing Better User Stories

Scrum: Writing Better User Stories
By Gordon McMahon

Recently we had a planning session where I was asked to explain what made a good User Story, so I thought I’d capture that in a short article.

We are all familiar with the standard layout of a User Story:

• As a …
• I want to …
• So that …

However, I’ve observed a temptation to just blindly follow that formula and then claim that you are “doing Agile”. For me, the real essence of Agile is looking at what you are doing, identifying if it’s giving you good value, and if not, changing it so that it does (or dropping the practice all together). So, how to we write better user stories ?

I’d like to start by breaking down what we capture with the above formula, what qualities we want from a user story, and then what we can do to improve our stories.

Role, Task, and Motivation

• As a … : This defines the role of the person stating the User Story and gives it a context. If you have the same value here for every story, “User” for example, then the field is not providing any value to you. You should take the one role you have and try to break it into finer grained roles, even if they are not actually represented that way in your system.

• I want to … : This is the task you are trying to achieve in the context you have just set up. Generally, people are quite comfortable describing this part. Concerns here are striking a balance between readability and capturing the necessary details. I’d err on the side of readability and make sure that the task part of the description is memorable and differentiates the story from others. You don’t have to capture all detail in this one line, you can add additional detail to a story outside of the “As a, I want to, Such that” structure.

• So that … : This is the motivation behind the story and, I find, often over looked when writing User Stories. I’m not suggestion you write a lengthy thesis on the motivations of the user, but at least explore it and see if there are some useful pieces of information to take from it.

Testability

A good user story should also capture some information about how you might go about testing the story. This can be in the form of a simple “Done” list, or perhaps as description of an integration level test/scenario(s) that would exercise it. I’ll assume that you would be writing unit tests (and writing them first) as part of the implementation.

Large Stories

A cardinal sin in my book is having huge stories that have such a complex completion criteria and cover such a wide range of functionality, that they take many iterations to be completed. These interrupt the rhythm of an agile project because it’s very hard to track progress against them. I’ve found that this can have a negative effect on the team morale as the story rolls on from one iteration to the next. We currently have a rule of thumb for our 1 week iterations, which is to limit estimates on stories to 3 days. If it looks bigger than that, I encourage the creation of sub-stories within it. So far, that’s working well for us.

Sure, you might find it useful to capture epic stories as a set of related functionality, but break it into bite sized chunks. Not only does this give you a warm feeling to the team as you close out all the sub-tasks, but the act if breaking an epic into smaller stories helps focus in on what exactly you are trying to achieve…which is what a good user story should do.

Conclusion

So do we write perfect user stories every time? No, of course not, but we often review stories in our retrospectives and identify which features of them made them easy to work with and which stories we had trouble with. I never expect a story to capture every detail, but I like to aspire for stories that anyone on the team could pick up and understand what needs to be implemented, why it’s being added to the product, and how they can go about verifying that they have finished the work.

Gordon McMahon is an agile software engineer based in Scotland. He has been practicing various agile development practices since 2000 when he was fortunate enough to spend a great deal of time pair programming and learning TDD with Paul Wilson. Since then he’s continued to learn more about agile project management and engineering practices and give training in the areas he’s most proficient. You can read more from Gordon on his blog.