As a full stack engineer, I have a tool set that I rely on every …
In Part 1 of our “User Stories 101” series, I introduced the basic model of a user story:
As a << user >>, I want << feature >> so that I can << receive value >>.
Now, I’d like to talk about the details included in a good user story.
First and foremost, a good user story allows us to easily have empathy for our customer or user. Sure, empathy has become a bit of a buzzword, but it’s important nonetheless. Knowing how our users can benefit helps us create better software to serve their needs. When we downplay the importance of understanding our users, we end up with terrible interfaces and cludgy experiences that satisfy requirements, but don’t delight.
Let’s take a look a closer look at writing good user stories:
Start With The User
They’re called user stories for a reason. We need to have a solid understanding of the user’s interaction with our software in order to write for them. I’m not talking about personas or demographic identification right now (although that is important). I’m more concerned now with who is actually using the system and what their technological abilities and constraints are.
In brainstorming the user role, simply name the individual type who will represent the role. Organize the set by sorting the roles into relationships between them – overlapping and adjacent roles. Some things to think about:
The user’s level of domain knowledge
The user’s technical proficiency
The user’s proficiency with the software
The frequency a user will interact with it
The user’s goal for using the software
The user’s context for using the software (mobile!)
From there, you should have a solid list of key user roles and how they’re going to interface with your product. It should become somewhat clear from this alone what key requirements are for each group.
A good story must also follow a solid syntax. This syntax is really well articulated in Mike Cohn’s reference, “User Stories Applied.” He co-opted the “INVEST” model for writing stories, which is:
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertical)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
Another key tenet of user stories is laid out here: stories aren’t a commitment, but a reminder. They’re a placeholder for a more detailed conversation and an overview of an idea.
As we break a story down into its component parts, we start outlining its needs. A few things that come alongside a user story in later planning are:
- Wireframes or UI design
- User workflows, content and form fields
- Acceptance criteria
- A development checklist and estimate
(More to come on some of those topics in a future post in this series.)
The closer you are to a story in your planning process, the more detailed it needs to be. Conversely, the farther a story is from an iteration, the larger and less precise it can be. These less precise stories are often called “epics,” as they end up containing large swaths of functionality and multiple stories themselves. They’re not bad stories, just big, and will ultimately get broken down into their component parts.
I write stories almost exclusively on 3×5 notecards. I love notecards. They’re cheap, physical objects that can be moved around, grouped together, or (my favorite) torn up. I also typically use a standard Sharpie marker, as the physical constraint forbids me from writing too much detail on a card. Sometimes I lay them out on a table, or tape them to a wall. They typically get grouped, organized, prioritized and discussed in great detail while they’re still physical cards.
Next time, in Part 3, we’ll talk about how to collect requirements for good user stories and actually write them. Stay tuned.
Editor’s Note: This series was originally drafted by Jon Arnold, but was not published until after he left Centresource for his next adventure as Product Manager at Taonii. You can find Jon on Twitter @jonarnold.