For many, Agile has come to mean “user stories.” So let’s talk user stories.
What is a User Story?
Agile teams break projects into clear chunks of functionality that they prioritize in a backlog. This way, they can deliver solutions effectively, one chunk at a time, with the flexibility to change course along the way.
But what do you call those chunks?
Sure, you can always go with “product backlog items.”
If you ask me, in keeping with Feature Driven Delivery, I’d use “features.”
But more often than not, people just go along with a term that’s become prevalent: “user story.” Most people don’t really care for the term “user story”—like “use case” before Agile came about. But hey, here and now, so be it.
More about User Stories
Kent Beck introduced the term “user story” as part of Extreme Programming (XP): individual “stories” to deal with requirements in a more informal and conversational way, instead of heavy requirements documents.
Then, in 2001, Ron Jeffries—who pioneered Extreme Programming alongside Kent Beck—used 3 Cs to describe good user stories: Card (“just enough text to identify the requirement”), Conversation (“an exchange of thoughts, opinions, and feelings”), and Confirmation (“confirmation using examples, preferably automated”).
In 2003, Bill Wake came up with the INVEST mnemonic to sum up the characteristics of good user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.
When writing user stories, many people have come to appreciate the “as a, I want, so that” template because it’s concise and helps crystallize who the customer is, what they want, and why they want it. Mike Cohn gives a few reasons why this template can be helpful.
And ideally, when building an app with different layers (screens, services, database), user stories are “vertical slices.”
The good
The good is that breaking big projects into small, manageable chunks of functionality is a good thing—whatever you call the chunks.
It’s also good to define user stories in a clear and concise way—using 3×5 index cards, for example—so they’re easy to grasp and prioritize.
And size matters: the smaller the user story, the easier it is to estimate, and the faster it is to implement.
The bad
I’ve seen user stories shrink—maybe because of the pressure to do more and go “faster.”
User stories turn into tasks, especially in large organizations where it takes more than one team to get something done. And people forget that a user story is supposed to be something valuable in itself.
With user stories shrinking, projects go from dozens of user stories to hundreds, and those stories become harder to prioritize and manage.
Smaller user stories also bring up details earlier and force earlier decision-making, leaving little room for design and creativity.
On top of that, individual user stories become technical in nature—not to say meaningless—so people have to start keeping track of groups of stories.
Basically, complexity goes up and people get caught in the weeds—the opposite of what we wanted with user stories in the first place.
So what
Whatever you call those chunks of functionality—stories, features, product backlog items, or something else—it’s important to remember what it’s all about: breaking projects into clear chunks of functionality to deliver value early and incrementally, one chunk at a time, with the flexibility to change course along the way.
Easy to understand.
Hard to master.
