Consultants and tool vendors seem to have a penchant for making things complicated. It seems the more complicated we make things, the more our clients need us. And that sells tools and services, I suppose.

On the other hand, I find unnecessary complexity extremely frustrating. It’s like the novel I read this week by a first-time author. It was good, but it had too many minor characters who complicated the plot and made the book hard to follow.

The same thing happens when people introduce complicated hierarchies or taxonomies for user stories like this:

You don’t need this. When teams are forced to use complicated taxonomies for their stories, they spend time worrying about whether a particular story is an epic, a saga or merely a headline. That discussion is like the minor character who walks into the novel and needlessly complicates the plot.

But, Mike -- I can hear you asking -- you’ve written about epics and themes before.

Yes, but those are labels. A story is a story so my recommended story taxonomy is this:

A story is a story is a story.

Some stories are big and they can be labeled as epics. I’ve used the analogy of movies before. All movies are movies but some movies are romantic comedies—that’s a label, just like epic is.

Similarly, theme refers to a group of related stories, but not does have to work within a hierarchy. Again using movies, I could have a group of spy movies that would include the James Bond movies and the Austin Powers movies. But a group of comedy movies would include Austin Powers but not James Bond.

So, again, theme and epic are labels not an implied hierarchy. Don’t make things more complicated than they need to be. I haven’t come across any reasons to have fancy story hierarchies or taxonomies.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

The more complicated these hierarchies, the more confusion. I have spent countless hours trying to undo the damage of people obsessed with knowing precisely what is a theme and how it differs from an epic. What is a “saga”? (Yes, some teams use that one, too.) And how features fit in.

I’ve ultimately given up and I just call them “groups” and “big ones” most of the time now.

Posted by Mike Cohn on 2016-09-08 23:45:45

Hi Mike,

Just wanted to add my two pennies to this discussion. I'm definitely in agreement with your position - a story is a story, and story splitting is hierarchical, with potentially many levels of splitting. "Epic" is just a label for a story that's large enough to warrant splitting.

Usually, the reason given for splitting epics is to make them small enough to deliver quickly (within a single sprint). But for me there's another reason which equally important, if not more so. I split epics to separate the high-value bits from the low-value bits, allowing the team to deliver the high value bits sooner and the low value bits later (or, possibly, not at all, by "trimming the tail"). For me, this is one of the key benefits of the backlog/splitting/prioritization/timebox aspect of agile delivery - it allows us to overcome the 80:20 rule - it takes you forever to deliver all the tricky edge cases - which are usually high effort and low value. This is, of course, all tied in with delivering an MVP as quickly as possible.

Michael Ball Marion made a comment about features being useful for decision-making purposes on large teams/projects - the ability to "manage" product or business change at a higher level, with different stakeholders involved.

I can see the value in this, but I have worked on projects where it has caused a problem. Senior stakeholders have prioritized the backlog at feature level, and declared an MVP at feature level, with the implication that _all_ sub-stories of a high priority feature being implicitly within the MVP, even the low-value high-effort bits. In particular, I have experienced this project on a project using the SAFe framework, which explicitly defines a hierarchy of epic->capability->feature->story (with a recongnition that stories can be sub-divided).

Tied in with this is the desire of stakeholders/managers to track the status of parent stories (such as features). The parent story (feature) isn't done until all its child stories are done.

There's also the problem of what to do with new scope items that relate to existing features. I already scoped the feature and split it down into stories, but I have a new story. Do I add it as a child to the existing feature (so management can track the "whole" feature)? Do I create a feature called "feature X part 2" and hang it off that? Do I use themes to group them together (that feels better). Maybe pairs of themes called "feature X MVP" and "feature X nice to have"?

I wasn’t attacking all tool vendors with this post, and definitely not yours. There are, though, a few tool vendors and consultants I had in mind who I think make this needlessly complicated.

Posted by Mike Cohn on 2015-07-08 12:22:41

Mike,

As usual, we aren't that far apart in the end. I guess I just wanted to expand the vision for how agile is applied in large organizations...and to defend us tool and services companies -- there is a well reasoned purpose for the hierarchy.

Cheers!

Posted by Michael Ball Marian on 2015-07-08 08:21:49

Hi Michael-

Well, I’m glad we disagree on at least something. :)

I appreciate your full disclosure. I hate it when I find out after the fact that someone had ulterior motives, which I’m sure you don’t. So, again, thank you.

What I am arguing against here are people who introduce artificial levels to a hierarchy based purely on size — e.g., “feature” is a big story but “epic” is bigger than a story. Oh, and “saga” is bigger than a feature. That isn’t necessary because those are largely the same thing. They differ *only* by size.

You are giving examples where things are *fundamentally* different. And I agree with you there. As for tools, I would want the tool to capture different attributes for a Portfolio Item and a User Story — because they are very different things. But “saga” and “epic”, etc. when they are just words people have introduced to needlessly complicate things (often in my cynical view to sell consulting work), it’s unnecessary. And that was my point in this post.

I suspect if you find us disagreeing, it is because you are bringing to my post your tool’s meaning for some of the words I’ve used (e.g., “feature”). Your tool (which I know) may have a very proper use of that term. But re-read my post with “feature” just meaning “bigger user story” and you’ll perhaps see that I don’t think we’re really far apart on anything.

Posted by Mike Cohn on 2015-07-08 01:30:57

Mike,

Wow! It is rare (perhaps this is a first) that I disagree with you as strongly as I do on this post. Full disclosure, I work for a well-known tool and service vendor. I won't hide my bias.

But first where we agree -- I DO agree that most organizations over-complicate their use of hierarchy. Even in the largest organizations, about 3 or 4 total levels (including stories) is enough. Most can get by with 2 or 3.

I do strongly disagree with you however that "a story is a story" and are enough to get the job done in all cases.

First, organizational size and complexity matter. For example, when you have a company with 5,000 or 20,000 people working on coordinated product efforts, and want to manage all of that work in once place to achieve alignment and visibility...you're going to have a rough time using a flat work structure. My experience has been that once your organization hits 50+ people, you probably need some grouping AND/OR hierarchy to manage things (I agree these are different, and serve different purposes).

Second, your post is engineering-centric, to the exclusion of almost everything else that goes on in any sizable business. Sure... an agile team or teams care about executing stories, period. THEY don't need much beyond that. However, agile businesses are much deeper. At the top levels, you have executives managing a portfolio of products and services. At a mid tier you have product, program and services managers who are in charge of complex product offerings. It is no longer tenable to allow these parts of the organization to act and manage in an ancient command-and-control silo fashion. They need to be every bit as agile as their engineering teams. Which brings me to my core argument:

Third, work item hierarchies are not (or should not be) just bigger versions or groups of smaller things. Properly implemented, each item in the hierarchy serves a different purpose, has different people "working" them, has different properties, and a radically different business work flow. Examples:

Above the story level you have something like a Feature, or a Marketable feature (the word used is arbitrary). These are NOT just big stories. They have a different set of properties. You make somewhat different decisions about Features than you do stories. At the feature level, you typically apply MoSCoW rules, Reinertsen's principles of product flow, and the like. You get marketing involved. You may or may deliver or talk about features at a trade show. All of that has significantly different implications than a story or theme-like grouping of stories.

Above that level, you have portfolio investments, initiatives, strategies or what you will. Now the properties and questions are investment-related. Are we building the right thing? Is it timed to market? Should we be investing more or less in this product? These are not "scope" objects like stories or features. And the people making these decisions don't want to wade into the details or understand 1000s of user stories.

To try to make a long story short -- properly used, hierarchies are about your business decision-making structure. I see them as completely indispensable for any sizable, fully agile and integrated business effort. I fully admit that MOST organizations don't understand the depth of this, and just treat hierarchies as "scope" buckets. In that sense, hierarchies don't help much.

Back to where we agree -- if your concerns are smaller, or even just limited to a large "silo-ed" engineering effort, sure, Stories are usually enough. If you want a fully agile business, you're going to need some structuring of concerns to create the right interfaces across your organization.

Posted by Michael Ball Marian on 2015-07-07 17:27:37

Good points, Rachid.

Posted by Mike Cohn on 2015-07-03 01:33:59

I like the idea of labels. Themes are something I use for my own and the business benefit (We use TFS, and I use "Themes" in the form of tags against a user story). They help organise stories when there are many around a particular.

For example a recent project do to with maps. I had themes for searching/UX/exporting/etc

#SearchingAs a y, I want to find n using xxx so that...As a y, I want to find n using zzz so that...

#UXAs a y, I want to differentiate between x on the map based on capacity so that...

#ExportingAs a y, I want to print the map so that...As a y, I want to email the map so that...

These especially help when playing back stories to stakeholders

Posted by Rachid on 2015-07-02 09:15:17

"What I want to say is that .... I do not want to say anything about it" .... This is a typical sentence which I use to emphasize 'uselessness'.

I full agree with the thoughts written here. 'In order to simplify things, we tend up making these over-complicated'.

If we understand the raison d'etre (reason of existence /creation) of any tools (digital or physical) to do 'more work', 'less effort', 'more quality' and most importantly 'happy faces' (teams, management and clients). However, we tend to use these tools to do 'less work', 'more effort', 'less quality' and 'unhappy faces'. The automation or reporting might improve due to these tools, however, these are 'never' the end-goals (these might be required but not the end goals). Honestly, automation and reporting are the 'whips in the hands of the management' used to overkill the teams.

The same story is with the Biggest word of the Digital age 'Process'.

Mike, I feel glad that you raised this important point (yet neglected by the by-the-book-management guys).

Thanks!

Posted by Gurpreet on 2015-06-27 17:54:37

Recently a collegue mentioned bis customer distincts between Story (=has to be paid) and Improvement (a JIRA categorization, is for free). Well, I told him what's the difference, beside that the customer tries to game you....

Posted by Nino Martincevic on 2015-06-27 05:32:32

I'm with you, Matt.

As for bugs / features, I tell people to envision a user calling our automated help line and hearing "Press 1 to report a defect and press 2 to request a new feature." My reaction would be, "I don't know! I just want different behavior! I don't care what you call it!"

Posted by Mike Cohn on 2015-06-26 13:15:46

I've been telling my teams this for years. A story is a story. Don't worry about if it's an epic or a theme, that just gets everyone confused. I don't even really like to distinguish between bugs/defects and stories. It's all work that needs to be prioritized and potentially brought into a sprint.

Posted by Matt Block on 2015-06-26 12:38:40

Can you use a more appropriate/less confined tool at the team level, and translate it into Rally and Jira, even if it's by hand?

Posted by Jeff Lindsey on 2015-06-26 08:57:20

You could be right, Fernando, about the novice-expert distinction.

I think there’s a human nature tendency to want to classify things and sometimes we just take it too far.

The tools discussion has been interesting because that was not even 1% on my mind when I started the post. Sometimes there’s some hidden reason that makes me write something. Not at all with this. I wasn’t thinking about tools one bit. But, for good or bad, tools force teams to work a certain way.

And back to your comment about beginners: For beginners, it can be great having a tool force them to work in what is often at least a somewhat reasonable way. But as the team improves those constraints becoming too limiting.

Thanks for your comments.

Posted by Mike Cohn on 2015-06-25 22:27:23

Great post Mike, fully agree with you.

Feels like when you're a novice (Shu), hierarchies help in order to structure out work, but as time goes on, the rigidness of hierarchies and the tools built around them (Jira is a great example) tie teams' hands and kill flexibility and focus on what's important.

Regarding the interesting comments below, the use of electronic panels (Jira, Trello, Rally, Mingle...), sound great at the begginning BUT end up as information fridges that require more dedication to the tool than to the User stories themselves...

Posted by Fernando García Jiménez on 2015-06-25 05:40:37

We have to use Rally and Jira, we just use Jira for teams and only user stories, in Rally we have to use Epics, Features and stories :(

Posted by Tom on 2015-06-25 04:09:23

Seconded. Jira seems to encourage the creation of a meaninglessly complex hierarchy that destroys transparency.

Posted by Sam Falco on 2015-06-24 16:18:15

Tell that to the Atlassian guys.

Posted by Ibrahim Khan on 2015-06-23 23:47:30

Great points, Matthew.

In classes I introduce these terms so people are familiar with them. But lately I’ve really been trying to downplay them to help emphasize that they really just aren’t that important. For many of us it’s human nature to overcomplicate things. I know I definitely suffer from that tendency in some aspects of my life. So you’re right that we need to avoid letting the tool become the focus. Thanks for that reminder.

Posted by Mike Cohn on 2015-06-23 21:14:13

Agree fully - the want for order and structure is counter to the ambiguity and discovery needed within a story. Epic/Story is as far as I suggest people go. Otherwise the tool becomes the focus rather than the delivery.

Posted by Matthew Tippett on 2015-06-23 15:08:20

Guilty as charged, although I’ve never promoted anything ascomplex as the graphic in the blog. Yet, when you have over 100 User Stories onthe Product Backlog and the project sponsor asks, “How close are you tocompleting the “manage my account” feature?” and the incremental development ofthat feature is made up of 15 User Stories spread across 8 Sprints, coming upwith a response without some identifier, label, or category is problematic.

It almost makes me wonder if we should bring back the old McBee Keysort cards (http://kk.org/thetechnium/one-..., the large cards that had holes punched around the perimeter, each hole representing a characteristic. So in our case, you might have a hole for each theme. If a card had a particular theme, you would notch out that hole with a special punch. And you could do the same thing for epics, feature groups, and anything else you wanted.

If you wanted to find all the stories for a particular theme, you would stick a long needle through that hole and lift up. The cards for that theme would be left on the table, since their hole was notched out. If you wanted to select an epic and theme, you would take the remaining cards and put the needle through the hole representing the epic, and so on.

We can do this more easily electronically these days, but in any case, there is something to be said for just selecting the attributes you want, rather than trying to force everything into a hierarchy (particularly ifa story might belong to two themes or epics).

Actually, going back to McBee cards might not be all that bad, as it would be in keeping with having physicalboards and not having our heads stuck in the computer all the time when we are trying to discuss the stories.