Deliver Value to Someone by Using Features
We hear a lot about stories, epics, and themes in agile. You might have other terms for your requirements, too. Let me explain some of these terms:
- Story
-
The smallest possible value to a specific user. It might not be sufficient to release by itself.
- Theme
-
Related group of stories. I call this a “feature set.” You can deliver any of the related stories and realize value.
- Epic
-
A compound story that’s not easy to tease apart. I find that epics often contain feature sets.
You might have other words for these terms, especially if you’re using a tool for your board. I encourage you to think about stories and feature sets. That will simplify your planning and delivery.
Here’s an example that might help. Assume you have an administration interface for your product. Different kinds of users (customers, internal sales people, external sales people, and company management) all want to run reports of some sort. Because there are different kinds of users, you’ll need some form of secure login. Each kind of person will have access to different data to run reports.
There are several login stories, all part of a feature set:
- Existing user login
- Ability to register as a new user
- Ability to change a password
- Ability to block a current user
- Ability to change a user’s privileges
- And many more
I can imagine several report stories: Report on sales by geography, by kind of product, aggregated by several customers for the internal people, and much more. Assuming each report type has more than one story, I would use the term “feature set” to describe each kind of report.
For the purposes of this book, I’m going to discuss stories and feature sets. I find that people too often lose the idea of stories when they start talking about epics and themes. The larger the chunk of work, the longer it takes to get feedback. That’s why I talk about stories and feature sets. Feature sets help people realize there are several deliverables. A story is one of those features.
Stories are small; epics and themes are not.
The story—a feature for a specific user that provides value to that user—is the unit of requirement in agile. If your thing—regardless of what you call it—does not deliver value to some user, it’s not a story.
Some teams work on what they call “technical stories.” Those are “stories” that allow the team to explore architecture or database schemas, or some form of design. Those are not true stories.
It’s possible your team needs to experiment to understand a feature more. That’s great. Create a user story, a real feature the team could release if it chose to, as an experiment. When teams understand who the feature is for, they are more likely to experiment in a shorter time and receive results they understand better.
You may have seen story advice that tells the team to break the work into tasks, such as setting up a database, or creating tests, or some other function-based work.
Don’t fall for that advice. Don’t create tasks or technical stories. The story is too large if you need to create tasks or technical stories.
Teams create tasks because they don’t understand the story’s user—who the value is for—or if the story is quite large and the first item of value is not clear to the team. The team thinks it will save time by creating what it calls technical stories or tasks.
In reality, the team wastes time because it doesn’t need the database or the UI or those tests yet. (The team might never need the technical story, once the team starts delivering value.) The first piece of value is much smaller than the task.
You don’t need to use user stories as your only definition of a story. However, I don’t recommend tasks or technical stories.
If you’re worried about making sure you have tests for a given feature, don’t make "testing" a task. Instead, limit the team’s WIP and/or ask the team to pair, swarm, or mob on the story. (See Work as a Whole Team to Create the Product, for details on pairing and mobbing.) When the developers and testers work together, they often create a better story, with the supporting tests happening faster.