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

Explore User Stories with Mountain Goat

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?

[sayedfaiztanvir]

Thanks for an incisive explanation to Epic, Theme, User Story and Feature. In fact, Jira has made it confusion or very strictly defined which is not the case. Keep up this good work!!Kudos!!!

[JohnnyCoraki]

I cannot describe the *relief* I've felt watching your series. I've been killing myself working to implement DevOps processes based on the toolset's prescribed functionality rather than what our team/organisation actually needed. This is so hepful.

[georgwagner]

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.

[soniakhan]

The way you explain stuff is epic. love it
🙂

[Emzy]

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

[gerac]

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

[marktossell]

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

[bgnfr]

Clarity and precision as always, thanks Mike!

[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.

[danielmiller]

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.

[jackharper]

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

[learner]

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

[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

[juanbarman]

Thanks a lot mate! Really useful information!

[matthewkramer]

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.

[andreasbecker]

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!

[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

[Mrdust]

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.

[GackFinder]

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

[prometheusj]

In Azure DevOps, the hierarchy is Epic-> Requirement -> Feature-> Task. Can you comment on the semantics or use of Requirement?