Agile Epic, User Story, and Feature: Do Names Matter?

Explore User Stories with Mountain Goat
* Mike's Free eGuide to User Stories bit.ly/3YTgGMQ
* All About User Stories: A Blog Series bit.ly/3KUgUNU
* User Stories & Story Writing Training bit.ly/3OOuYJJ
All of the terminology we use to describe backlog items can get so confusing: epic, PBI, user story, theme, feature, saga, Jira epic, initiative. The list goes on!
It doesn't need to be that complicated. Mike Cohn of Mountain Goat Software, and author of User Stories Applied, gets to the heart of all the many names for product backlog items, and proposes that we at least try to keep it simple.
Inside this Video
00:00 Introduction
00:28 Product Backlogs and PBIs Explained
00:56 What Are User Stories?
01:29 User Story vs Product Backlog Item
01:55 What's an Epic? What's a Theme?
02:49 Agile Tools & Vocabulary Confusion
04:01 What Is a Feature?
04:32 Feature vs Epic
04:44 Saga and Initiative
05:04 Tag Terms for Your Convenience
06:09 Everything Is a Product Backlog Item
06:40 Is Your Hierarchy Complicated?

[@soniakhan8525]

The way you explain stuff is epic. love it 🙂

[@MountainGoatSoftware]

Thank you very much. That's kind of you to say.

[@georgwagner5577]

I was about writing a summary for myself and suddenly I heard "Jira, I'm looking at you!" :D made my day at 10 a.m.

[@MountainGoatSoftware]

😂

[@philippebourgeon8451]

Clarity and precision as always, thanks Mike!

[@MountainGoatSoftware]

Thank you, Phillippe!

[@Emzy172]

Sometimes people spend too much time debating whether something is an epic or story instead of defining the user need. I think tools such as Jira have contributed to this

[@MountainGoatSoftware]

I totally agree.

[@gerac]

I really needed this explanation... trying to understand all these definitions was driving me crazy! Thanks a lot, Mike!!

[@MountainGoatSoftware]

I'm glad this clicked for you!

[@marktossell8461]

Very helpful. Love this: "They're just labels." Thanks, Mike.

[@MountainGoatSoftware]

Thanks, Mark!

[@oboroscom]

Thank you for the simple yet concise explanation. I would really enjoy seeing this information accompanied by infographics or possibly using one of the tools(Jira, Monday, Clickup etc.) that can visualize what was explained.

[@MountainGoatSoftware]

Thank you. I'll talk to my video editor and see what we can do on graphics. I tried to stay pretty tool agnostic because the ideas I'm discussing apply regardless of tool. But there are tool-specific topics that could be worth going into.

[@talentedtitans8593]

Beautiful explanation Mike .

[@MountainGoatSoftware]

Ahh, thank you!

[@juanbarman]

Thanks a lot mate! Really useful information!

[@MountainGoatSoftware]

You're welcome!

[@pareshgheewala8933]

superb and precise explanation.

[@MountainGoatSoftware]

Thank you!

[@Srkntrkl35]

Quite simple explanation. Thanks 😊

[@MountainGoatSoftware]

Thank you!

[@danielmiller2886]

This is a new concept for me, because the software we use (IBM Rational Team Concert) has them all as a hierarchy. Groups of stories make up and epic. Groups of epics make a Theme.

[@MountainGoatSoftware]

A hierarchy such as that is very common. I think it can be useful up to 3 levels but some tools and teams go nuts with as many as 8 levels (I think that was the most I've seen).

[@danielmiller2886]

@@MountainGoatSoftware 8 levels, that IS nuts!

[@learner8084]

THanks a lot... I think your explanations are great !

[@MountainGoatSoftware]

You're welcome

[@derrick0217]

Please do an agile tool tier list!

[@MountainGoatSoftware]

I'll see what I can do.

[@jackharper6746]

for me an Epic is an area of functionality e.g. finding parking in a map app. a feature would be filtering by price and a user story would be one or more features that are to become functional requirements

[@MountainGoatSoftware]

Great set of definitions.

[@andreasbecker8754]

Thanks a lot for your helpful video! I am even more struggling with the process of how scaling is done for multiple teams in my professional environment. In our process, being loosely based on SaFe, we are planning "program increments", i.e. planning horizons of roughly three months, for a bunch of teams. Features are registered by several stakeholders, which jointly get prioritized by the whole group of stakeholders. Teams estimate these features - in most cases by BREAKING THEM DOWN into what exactly has to be done, resulting in a bunch of tasks or user stories. Is this planning of a three month-timespan and breaking things down more of "following a plan" than "responding to change"? I am not quite sure about it. Besides that, ever ongoing discussions such as "this is not a feature! That should be an epic!" are energy-sapping and do not provide any value at all. Once again, thank you, Mike!

[@MountainGoatSoftware]

I think a really good aspect of SAFe (and what you describe) is the emphasis on goals further away from a sprint. When a team goes from short-term goal to short-term goal it can be sub-optimizing. A team should have a bigger goal out a bit further into the future, and I think 3 months is great. BUT I don't think a team should break anything down beyond the first sprint toward that goal. Doing more than that is unnecessary and very likely wasted work as things change over the 3 months. A good rule of thumb for looking ahead (in any way) is to do only do it if it results in different behavior today. So if we want to break things down (a bit) so we can decide if we need an additional team or the work is the approximately right amount of work, that's great. If not, don't do that extra upfront work.

[@Enterprisemarketer]

Great content!

[@MountainGoatSoftware]

Thank you!

[@karmarkarganesh]

nice information...helpful

[@MountainGoatSoftware]

Thank you.

[@matthewkramer8613]

It seems like its a task to just break a project down so it can fit into the Agile terms. This in a way is a project in its self. keeping it simple is best unless the a granular approach is required.

[@MountainGoatSoftware]

Agreed. I don't like it when I see teams that are trying to work with this cumbersome hierarchies.

[@l_combo]

nice explanation, thanks for that and plenty for me to think about with my team. I noticed you mentioned the term initiative for something that spans a year or so - also what I would refer to as a program (something with a goal that is larger than a few teams and requires coordination across the organization). How do you think about programs and the coordination of work outside the boundary of a team(s) product backlog when work needs coordinating and scheduling to occur around a deadline (e.g. a regulatory due date) What are your thoughts in a product roadmap being outcome based so people make the topmost grouping of work as an outcome rather than in a story format - this way the result is described rather than the solution so that teams have more autonomy over the how. You can take this further with organization goals such as things like OKR and the relationship between stories / themes and OKRs. Would also be keen to get your take on that as well.

[@MountainGoatSoftware]

The language around agile has gotten very polluted with every tool vendor introducing their own terms for all the levels their tools support. So initiative, program, etc. doesn't really matter. As for roadmaps being outcome based: Yes, I think that's great. If you think about a hierarchy from something like program or initiative to feature to epic to story to task, they'll all end with very tactical "do this" and "do that activities." The deeper into their hierarchy the team can stay outcome focused, the better. So absolutely at the upper levels, including with OKRs. I've worked with quite a few orgs using OKRs and I'm torn on them. They seem like they should be very helpful but nearly all organizations don't get the benefits from them it seems like they should. They seem more promising than they deliver unfortunately.

[@Rekettyelovag]

You briefly mentioned that these terms shouldn't be used as containers. But I saw that lot of companies see these are hierarchical containers (usually each level has its own rules, owners and responsibilities). The current employer I work for uses them this was as well. "task < pbi < feature < epic < opportunity" and of course we have other backlogs for bugs, technical debts and whatnot. I can't keep tracking. //No they don't want to change this

[@MountainGoatSoftware]

Yes, many organizations use the terms as a hierarchy (as do tools) and it creates confusion. Then we spend needless time trying to figure out if an item is an epic, a feature, or some other term.

[@Rekettyelovag]

@@MountainGoatSoftware And this is not even the biggest problem because people practicing agility could solve this by common sense. The problem is the owner hierarchy and blocking processes. If you'd like to fix a bug, for example, and you are required to consult with multiple people who "own" the epic, the feature, etc. This is just one example, but there could be multiple blocking factors and processes to burn time and patience in the name of quality control and whatnot.

[@johannashuler39]

This was helpful. Do you have any videos about writing user stories Gherkin format?

[@MountainGoatSoftware]

Thanks, Johanna. I don't have any stories specifically about Gherkin.

[@vo-Blog]

I think it's better to use them as tags while building the backlog. Then it becomes easy to develop your "definition of done " as well as enable the PO to easily draw them in other of preference into the spring backlog

[@MountainGoatSoftware]

That's a great way to keep the backlog organized even early on

[@M0rd7ust]

In my experience of "imposed agile", work items (WI) of different sizes are used as offered by the software in play (Jira / Azure DevOps / ...), resembling the org hierarchy and positions which manage and are accountable for those items. Some org levels might deal with multiple WI levels. In my case, it's a century-old tech company struggling with its politicised and tech- and market-disconnected management; IIRC, we have 5 levels of WIs (PBI/Feature/Epic/Global Epic/Opportunity). It works for creating an agile facade, but is not a great thing for our customers IMHO.

[@MountainGoatSoftware]

There's probably some relationship between the number of layers of management in a company and the number of layers in the backlog hierarchy. 😞 In my opinion, in both cases, the fewer layers the better.

[@brianstark1527]

Great explanations!! We use a SAFe-like framework. What are your thoughts on hierarchy and levels of ownership in scaled scrum environments?

[@arasgeylani]

SAFe is not agile so why bother what it calls anything?

[@MountainGoatSoftware]

Thanks, Brian. I may be missing a nuance to your question but I'd prefer flat over a hierarchy, whether that's the org structure or a backlog item structure. And I'm much more in favor of shared (collective) ownership rather than designated one person to own something. I understand why orgs like that ("a single, wringable neck" is a frequent, unfortunate, phrase). But when ownership is assigned to one person, it decreases any ownership felt by others.

[@majuodawlkis]

@@MountainGoatSoftware - We use MS ADO. One of the reasons we have been pushing for a hierarchy has been for cross-project report out. As we are trying to report out the 'value delivered' at a Director/VP meeting, we found that most User Stories were too fine grained to be meaningful. but grouping the User Stories into larger grained Features or Epics had more meaning when reporting across Agile projects. Would you recommend using Tagging for this purpose? I still don't think I would be able to get to the larger grained meaningful unit of work. Thoughts?

[@GackFinder]

5:40 20 jokes plus a kiss is a successful first date.

[@MountainGoatSoftware]

Good acceptance criteria!

[@ziddib8522]

Can you share the original relationship among them. I mean which comes on top

[@MountainGoatSoftware]

Sure! The easiest way to think about the relationship between them is that the bigger the story the higher up the backlog it should go. So big epics should be higher up than smaller features. The lower down the backlog you get, and the closer to development that you get, the smaller the stories should be. If you need a good visual there's a great one here: www.mountaingoatsoftware.com/blog/stories-epics-and-themes

[@rupalichaturvedi4509]

Can you please help in understanding difference between epic and feature

[@MountainGoatSoftware]

Sure! In general, a feature is a user story that is big enough to release or big enough that users will notice and be happier. An epic is a really big user story. I won't be able to complete an epic in one sprint or iteration, but I might be able to complete a feature.

[@user-ok3ws6to2i]

Mike, can you help me with a question about user story roles? I'm a new Scrum master and I appreciate they should be written from the POV of an end user. How does this work for the infrastructure stories? The team either end up not using the template structure: As a ..I want or writing it from the POV of the Product Owner / Developer. Is there a definitive answer on this? Any thoughts will be gratefully appreciated. Thank you.

[@MountainGoatSoftware]

Hi Helen, I'll be happy to help. User stories should be written from the perspective of a user or customer. I'm not opposed to an _occasional_ story from a developer for product owner perspective. But those are a bit of a danger sign if used too frequently. For infrastructure stories, I suggest using _job stories._ I'll have a new video here on February 21 about them. But the basic idea is to replace "As a type-of-user" with "When___" The when contains a trigger or situation. A simple example for a refrigerator would be, "When the fridge door is left open more than n seconds, I want the fridge to alert me so that I can close the door." No user in sight on that story! The use is less important so it's replaced by the event initiating the story. You can read more here and I'll have the new video up in a few weeks. www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories

[@user-ok3ws6to2i]

@@MountainGoatSoftwareThat is extremely helpful Mike - thank you so much. I've already shared your advice with the team. Looking forward to the video and keep up the outstanding work. 😊😊

[@MountainGoatSoftware]

@@user-ok3ws6to2i You're welcome

[@oscaroscuro]

so, a theme can be a feature? I dont understand the difference between a user story and a BIG user story. who decides that a user story qualifies as big? I'm interpreting it as: you can have multiple, related, user stories (theme?) and combine them into one user story to make it "big" (epic?). Also, you said features are epics that are big enough to be released. Does that mean that in order for a PBI to be released it needs to be big? Does the size matter for it to be released?

[@MountainGoatSoftware]

Great questions, Oscar. Questions like "who decides that a user story qualifies as big" are why I'm not a huge fan of how tools implement these terms. Many tools create hierarchies and you are forced to choose between things like Story, Epic, Feature (or more) when creating the item. I think the question is analogous to who gets to decide if a movie is a comedy. If the movie has at least one joke a minute, is it comedy? What if it goes 30 minutes without a joke then has a really good joke? The distinction is meaningless. Who cares if it's a comedy? I just want to watch a good movie. The way I think about it is you have stories. Some stories are big enough that we want to split them into smaller stories. Think about adding a spell checker to Microsoft Word (way back when). That's a single story but it's big so I'd call it an epic. As an epic (big story) it's too big to finish in one iteration (or sprint) so we want to split it up to make it more convenient to work with. Maybe we pull out sub-stories like adding words to a custom dictionary, sharing dictionaries, installing them, etc. So imagine we started with the big epic ("As a user, I can spell check a document"). We split it into let's say 8 sub-stories. And now we're told, "Don't work on the spell checker, improving the table designer is more important." We then put a rubber band around the 8 substories and call that a theme. (A group of related items.) It gets confusing because Jira decided to use the terms differently--they call the group of stories an _epic_ instead of a _theme._ I don't use the term _feature_ at all. But others do and usually use it to mean a story of any size that can be released.

[@oscaroscuro]

@@MountainGoatSoftware thank you for taking the time to explain more. I think you answered some of my questions in your video during the second half, but I was still processing the terminology from the first half during your explanations. It helps to also hear the same explanation worded differently. Thanks again.

[@MountainGoatSoftware]

@@oscaroscuro I'm glad I could help