nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Breaking down stories into sub-stories

David Corlette1

Hi folks,

I've been working with JIRA/Greenhopper for a while now but I'm just starting to play with the newer version. It seems like Atlassian has set things up so that one can create Epics, break those down into Stories, and then add sub-tasks to the stories.

This seems like a fundamentally limiting approach - an Epic is just a big story, and we routinely break stories down into sub-stories, sub-stories down into sub-sub-stories, and so forth.

Here's a simple example: let's say I have a story: "I spent too much time on plug-in management - finding, installing, and updating plug-ins. This needs to be easier."

This is a really big story, perhaps years of development. So I break that down into sub-stories: "I want to be alerted within the product when a plug-in update is available", and "I want to have one website to go to to find plug-ins even if they come from third parties."

This latter sub-story is still too large for a sprint, so maybe we break that down: "I want to be able to easily go to a website and search for the plug-in I want", and "I want to be able to get standard and third-party plug-ins from one place."

And so forth...

My take on this is that Atlassian may have boxed themselves into a corner by defining a separate issue type called an 'Epic' instead of just defining an epic as 'a story with linked sub-stories'.

Am I correct here? Or am I missing something?

Accepted answers

David Corlette1

It looks like no one has discovered a way around this limitation - I guess I'll use the standard Epic/Story breakdown and supplement with themes and similar. Oh well.

All comments

Chris McFadden

I think that having the simple hierarchy of Epic->Story->Subtask has many advantages to a big tree of variable depth - which is really complicated to manage in any tool or for folks to understand. As you groom your backlog you can split up stories (clone) and refine the acceptance criteria until they meet the INVEST critiera and are suitable for inclusion in a Sprint. If you think about it, having stories that are abstract stories with children stories, that have children stories, etc how do you manage all of these additional artifacts? Do they have a status? Do they get delivered? Seems like a lot of extra overhead.

Matt Schenck

Hi David,

My name is Matt and I am one of the Product Advocates here at Atlassian. First and foremost, thank you for reaching out!.

I would ask which version of GreenHopper you are using? In 6.1, we introduced a completely different UI that handles Epics more as themes, such that an Epic never makes it onto the Work board (because as you point out, an Epic will never be completed in a single sprint), but every non-Epic issue type can be easily linked to that Epic/theme, and the Epic now in the Plan board, gives a sense of what percentage of it is completed, how many story points are associated with it, etc. Further, in the Report board, there is now an Epic Report, giving a sense of where that larger story exists.

I hope this helps David, and if there is anything else that I can do to help, please do not hesitate to reach out.

David Corlette1

The latest GH.

David Corlette1

Well, this is obviously a philosophical difference more than anything else, but I can tell you that other scrum tools with which I am familiar (most notably VersionOne) allow arbitrary levels of nesting of stories. The act of breaking down a story causes the parent story to morph into an Epic (in V1); you can look at the backlog as an Epic Tree or a flat ranked list; V1 has its issues but "manag[ing] all of these additional artifacts" isn't really a problem based on my experience. What I come back to here is that Greenhopper appears to be forcing us into a particular way of managing parent-child relationships among Epics/stories/tasks (or boulders/rocks/pebbles, if you prefer), which is in sharp contrast to how the product is described: "GreenHopper leverages JIRA's customizable issues and flexible workflow to provide an Agile project management tool that adapts as a team evolves." Apparently this is only true if your team never evolves more than one level of parent-child story relationships ;-) The real question here is whether anyone has found a way around this difficulty, or any better way to manage/view the hierarchy. This could be using Issue Links to reference parent "Themes" or similar - all ideas are welcome. True confession time here: I'm actually no longer in Engineering, I'm a newly-minted Product Manager. I'm trying to use Greenhopper to manage a "Market Problem" backlog, which is a little bit different than an Engineering story backlog. Mostly the same principles apply, however, with some subtleties I'll ask about in other threads.... Thanks all for your responses thus far, keep them coming!

David Corlette1

It looks like no one has discovered a way around this limitation - I guess I'll use the standard Epic/Story breakdown and supplement with themes and similar. Oh well.

Jim Constant

I know I'm dredging up an old thread here but I'm struggling a little bit with the implementation of epics in JIRA too.

I'm about to kick off a project and I've got a backlog of ~100 large stories or epics. But I've entered them as stories. I've also created epics in the JIRA sense which are really more like themes. Now, some of these large stories will probably breakdown into bite size stories but some will probably breakdown into smaller, but still large stories (epics by the common definition).

So I could quite easily have 100+ epics if I convert the stories in my backlog. But if I want to breakdown an epic into smaller epics, it seems a little clunky to go through the steps of creating the new epics and then the stories that the epic might contain.

Is there an easier way to manage stories and epics that I'm missing?

Sal Quintanilla

I'm of the same mindset of wanting to hierarchically break down my epics and stories as needed down to reasonable containers of sets of tasks that should be implemented together. I've read several Agile tool comparison articles that have said JIRA Agile, Rally, and VersionOne are "almost the same in features", but this deficiency is a significant disadvantage to JIRA Agile.

I came on here hoping that there was a way to enable supporting sub-stories, sub-sub-stories, etc.,. Is such support available? If not, is it possible, or is the design purposely disciplined to use only shallow hierarchies?

We're using JIRA Agile 6.6.0. Thanks for any insights provided.

Jonathan MacDonald

@David Corlette, Have you ever found a better solution?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software