Software Development Practices: Telling Your User's Story
Last week was the first in a series of posts about product development practices. In that post, Shelley discussed how important it is to identify the problem that the user needs to solve. This post will describe how anyone can write and understand user stories that articulate the problem.
What are User stories?
User stories are informal, simple, short and concise statements about what the user wants to accomplish. They focus entirely on what the user wants to do and deliberately avoid talking about how the technical solution will work. They’re usually brief, in fact, teams sometimes even write them on 3x5 cards or Post-It notes. They take a very simple form:
As a . . .
I want to . . .
So that . . .
“As a . . . ” Describes who is taking action. The who is important to capture for a lot of reasons. Different users have different needs and goals and potentially have different roles or permissions: “As a library patron” is very different than “As a library staff person”.
“I want to . . . ” Describes the user's actions. It is the essential what that outlines what the user wants to do. At the end of the development process, this should line up with the new feature(s)
“So that . . . ” Describes why the user wants to take this action in the first place. There is a world of context in the “So that . . .” For example, knowing that the user wants to print from the holdings screen because they need spine labels helps developers make informed decisions about the how further down the road.
User stories are powerful because they are accessible both to non-technical staff and to developers without domain expertise. They create a middle ground of understanding based on the most important player in the development process: the user.
Creating User Stories
Let’s look at a real world example, using the demonstration application for WorldCat Registry Hours. This application was inspired by our activities at Developer House last February and it uses the WorldCat Registry RDF interface to provide a basic display of library hours information. While it is a relatively simple application, it actually has several different stories associated with it. Our first example is the story for displaying the main library hours:
As a library patron,
I want to view my library’s hours and determine when the library opens and closes
so that I can pick up a book on hold.
When writing stories it is critical to keep them small and focused on a single feature. A complete application might have many stories associated with it - one for each piece of functionality being built. In the case of the WorldCat Registry Hours demo, there are six stories you can look at in the GitHub project.
When writing a user story, it's worth taking the time to really make sure that the “So that . . . ” gets to the heart of the user’s goal. Does it communicate what they really want accomplish? For example, let's start with a first draft of a user story:
As a patron
I want to see the library address and hours
So that I can find a library near me that is open
While everything about that story makes sense, when I look at it more closely I find myself thinking, “hmm, that ‘So that . . .‘ could be written as an ‘I want to . . .’ instead” and it might make the story more accurate and more compelling:
As a patron
I want to see the libraries near me that are open today
So that I can go print out a FAFSA form to fill out
Re-crafting the story this way clarifies the user’s real problem and gives us a better understanding of what functionality they might - or might not - need.
When to Use Stories
As a product staff person at OCLC, I create user stories at the start of each release for a product. At the team’s initial release planning meeting, these stories are used as talking points to allow developers and product owners to build a shared understanding of what is going to be built. Conversations about the stories often result in stories getting reworked because they are too large, imprecise, or complicated. Imprecise stories are reworked until the team feels they are clear and are happy with them. Complicated or too large stories usually lead to additional, smaller stories.
During the development process, user stories get revisited and are used as a touch point for what the system should and should not do. Sometimes new stories get added during the development process to cover a feature that was overlooked in the initial planning. User stories can also be used to communicate to project stakeholders like the library director:
- What is being built
- What isn’t being built
- How users will benefit from the project
User stories are also the basis for Acceptance Criteria, which are the focus of our next post.
Senior Product Analyst