For the ninth installment in this blog series about “20 Controversial Topics of Debate in Agile“, let’s talk about some terms that are often used in Agile to describe stories.
User Stories in Agile describe the goals of a user from their perspective. Stories may be written at different levels of granularity.
All the items listed below may be “stories”, in a sense, but they’re different sizes. The higher an item is on this list, the less detail you will have. As you get closer to a level that is “suitable for development”, the stories will be much more detailed.
In this chart, I put themes, epics, and features at the same level. Some people use these terms interchangeably, so I won’t argue about what they’re called (but you can!).
In my opinion, it’s not really about what something is called; instead, it’s about how big it is, and if it can be developed within a sprint. Any item at the planning level will be too large and wouldn’t be completed within a single Sprint.
User Stories at the Execution Level are not too big or too small, but like Goldilocks, they’re “just right”.
Too Small
Just Right
Too Big
Themes / Epics
Depending on what level you are writing stories at, you could have less detailed titles. If writing at the epic level, you could just include the core idea, rather than going through the trouble of writing it in story format. An example of this might be:
“Customers”
This would include all the things needed to add and maintain customer records.
Feature Stories
For features at the next level, if you don’t feel you need a full user story, I suggest using the Verb-Noun approach. Following on the previous example, a feature might be:
“Add Customer”
User Stories
Going down to the actionable level requires that you include more details. Continuing the previous example, a few user stories for the “Add Customer” feature might be:
- “As a prospective customer, I want to see the benefits of becoming a customer, so I can decide whether to sign up”
- “As a customer, I want to be able to create a new account myself, so I can make purchases”.
- “As a customer service rep, I want to be able to create an account on behalf of a new customer, so they can have an account to use for shopping”
Tasks
User Stories represent who, what, and why, whereas tasks describe how to develop the solution. Sometimes tasks can be converted to stories, and sometimes stories can turn into tasks, depending on what they are.
Wrapping up…
Now, if you really want to be confused, I suggest you also look at Jeff Patton’s User Story Mapping technique and book. He uses some different terminology in his approach to organizing User Stories (borrowed from UX) to provide a more holistic and organized view of a product. My point being, don’t get hung up on what things are called, just recognize when or when not to pull a story into a Sprint Backlog. Now, it’s your turn. Tell me what you think in the comments below!
Next up in this blog series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can Agile co-exist with Waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?