Requirements vs. Stories
What it takes to Design at Scale
“We’ve been told we’re switching to Agile, I’m a little confused about how we’ll capture all the requirements in time…” Maybe you know this story. Maybe this is you. Other questions here include “can fonts, colors, etc. be captured in user stories?”
The answer is…no. Emphatically, no.
“But…my organization”…sorry, still a no. There’s a good reason for this though, and you’ll see as the story unfolds.
What are User Stories?
User stories remind us that the customer is the center of what we’re doing (at least they do when we do them right). User stories communicate intent, and can help us understand our common goals as teams. At their best, user stories are supposed to be snapshots of high level functionality that create alignment.
Alignment is when an organization is reoriented to work efficiently together toward a common goal. The thing is, you can’t work efficiently while trying to cover the minutiae of every single line of code in requirements.
Don’t take my word for it:
“A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.” — Agile Modeling
What does a good user story look like?
There are a few parts to a good user story:
- Describe who it’s for-
This is fundamental, as knowing your users helps you design the right thing. And don’t say everyone ages 0–90. If you don’t have access to a formal research team, try talking to your current customers. If you’re a startup, talk to potential customers and figure out if you’ve found a niche in the market.
- Describe what you want to do and why-
Don’t take for granted that people will think it’s obvious why you want to introduce an enhancement, feature, or product to the existing code base. Again, user stories are for alignment and the spirit of Agile is collaboration.
- Make sure the benefit is obvious from the beginning-
Make the user value obvious. A good user story helps the team envision the user benefit being derived from the feature or enhancement or product. If you can’t answer this yourself, or if other people have some push-back, take that feedback and make something stronger with it.
Example User Stories
A major advantage user stories have over requirements is that the word “requirement” suggests that a feature is required where often it is just desired. A good user story doesn’t get caught up in the solution, but rather describes a pain the user has that the team can solve.
Example One: The Basic Formula
As a (user type), I want to [do this thing] so that [I get this value].
Example Two: A Basic Story
As a (customer), I want to [hail a ride] so that [I can get to where I am going].
That’s it. That’s all there is to it. There might be many of these, and you might have features that break down in there. For example, if you write a feature for accepting credit card payments, you might need to specify which cards, but that would be for epics.
Design at Scale
So, what does this have to do with design at scale? Well, on a team of one, or in a small organization, design can get siloed. In a large organization, the goal and work of UX is to create the atmosphere for collaboration. Contribute to stories, share the envisioning process and work together to do great things. My mom always told me since I was little, “If you want to go fast you can go alone, but if you want to go far, go together.”
Hey! You made it! If you want to know more about the Agile methodology or how to implement it check out Lean UX. Thanks for reading!