User stories, epics, themes, features, backlog items, initiatives, sagas.
It gets so confusing and it doesn't need to be.
In this video, I'm going to explain these terms and then I'll explain why I don't use a complicated user story hierarchy and why you probably shouldn't either.
Hi, Mike Cohn and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil and want to help you too.
Most agile teams have what they call a product backlog, using a term introduced by Scrum.
At its simplest, a Product Backlog is a list of things to add to or improve in a products.
A Product backlog comprises product-backlog items.
That is, each thing on a project backlog is product backlog item.
Since that's a mouthful to say or a lot of characters to type, you'll see it often abbreviated as PBI.
The Agile process extreme programming introduced the idea of user stories.
These are short, simple statements told from the perspective of a user.
Imagine team members talking to users and saying, so tell me a story about how you use this new system we're building for you.
I'm using software to control my camera right now.
If I am asked to tell a story about how I'll use that software, I might say that I want to be able to easily zoom my cameras in and back out.
That's a user story.
Here's the first problem.
User stories have become so common in Agile that a lot of people will use user stories and product backlog items interchangeably.
I get it.
If, let's say, 80% of your product backlog items are user stories, you just fall into the habit of calling them all user stores.
We're not going to do that today, though, as I want to be very precise in using these terms.
User stories were invented by a team at Chrysler.
When you invent something, you should be allowed to define the vocabulary.
And they did, defining the terms epic and theme.
Epic was used to mean big user story.
Think about watching some awesome superhero movie in a movie theater.
As you leave the theater, You turn to a buddy and say, dude, that movie was epic.
It was big.
There was lots happening on the screen.
It's the same thing with an epic user story.
it's big!
The other term they defined was theme, which meant a group of related user stories.
Suppose you're working on a system that has 10 stories about account management, and maybe there are 15 user-stories, each describing a report that users need.
These are themes, groups ofrelated items.
If I've confused you with Epic and Theme, it's likely because some of the tool vendors use the terms differently.
Jira, I'm looking at you.
These tools will use Epic to mean a group of related items.
I don't know if this was a deliberate vendor lock-in strategy, or if a programmer made a mistake on Tuesday, released the software on Wednesday,
and by Thursday it was too late to rename the feature.
In any event, it's created confusion in the Agile world about Epic and Theme.
I've kind of given up and I'll often refer to them as big ones or group.
No one can redefine those terms out from under me.
You'll want to use Epic & Theme the way your tool does.
But be aware that if you read articles or books, you might encounter the original and what I consider the actual definitions.
So we've got a product backlog, on it are product-backlog items.
Some of those product backlogs items, perhaps most for some teams, are user stories.
some user-stories are big, and we call those epics.
And user story can be grouped into themes.
Next up is the term feature.
Most commonly, this means a product backlog item that is big enough it can be released to users.
If you're building software to control the color of smart home lights, you probably wouldn't release a backlog that let users set only the red value of
the light.
but letting users control the full color spectrum by setting red, green, and blue values is big enough to release.
So that would be a feature.
Feature is similar to Epic, at least how Epic was originally defined.
Epic just tells us that a story is Big, but Features tells it's big ENOUGH to be releasable.
Some organizations or tool vendors add even bigger items on top of this.
Sometimes saga is used to mean something bigger than an epic, and initiative is use to means something taking perhaps a year to do.
Something this big shouldn't be on your product backlog, so I'm not sure why we need a name for it.
I recommend you think of these terms as labels or tags that can be applied rather than as a strict hierarchy.
This is because some features are bigger than some epics or themes.
There's not a magic size when an epic becomes a feature or the other way around.
Think of tagging movies in your movie library software.
I want to tag some movies as action movies, some as comedies, and perhaps some romantic comedys.
Is there a strict definition of these?
If there are 32 jokes per hour, does that make it a comedy?
If there are 20 jokes plus a kiss, is it a romantic comedy?
It doesn't work that way.
Action movie, comedy, romantic-comedy are just labels we can apply, and we do it for our convenience.
The same should be true of terms like user story, theme, epic, feature, saga, or initiative.
They're just labels.
Use them if they're convenient, or I guess if someone in your organization is requiring them.
I think of everything on my product backlog as a product-backlog item.
Some are big enough that they contain smaller backlog items within them, and some of those small items contain tiny items.
To me, it's quite simple with a recursive relationship.
i don't need a bunch of terms that can create confusion.
And when I do want to indicate that a backlog item is big, releasable, or related to other items, I can tag those items.
No complicated hierarchy needed.
Is your team using a complicated product backlog item hierarchy?
What benefits do you see to that?
Any challenges?
Do you use terms other than the ones I've described?
Let me know in the comments.
I read and appreciate every comment.
If this video has been helpful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.