For many, Agile has come to mean “user stories.” So let’s talk user stories.
What is a User Story?
Agile teams turn projects into chunks of functionality that they prioritize in some sort of 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 of functionality?
Sure, you can always go with “product backlog item.”
If you ask me, in keeping with Feature Driven Delivery, I would use “feature.”
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 using a large requirements document.
In 2001, Ron Jeffries, who pioneered Extreme Programming with Kent Beck, used 3 Cs to convey his take on 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. For example: “As an iPhone user, I want to log into the app using my fingerprint, so that I don’t have to go to the trouble of typing in my username and password.” Mike Cohn gives a few reasons why this templates 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 good to define user stories in a clear and concise way (using 3×5 index cards, for example) so they are 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 that’s due to pressure to do more and go “faster.”
User stories turn into tasks, especially in big 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 user stories become harder to prioritize and manage.
In addition, smaller user stories bring up details earlier and force earlier decision-making, leaving little room for design and creativity.
And 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 user 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.
