How to structure ticket Hierarchy - epic vs story vs task etc.

[Christian Hultin]

Hello Everybody,

I am currently working on creating a new structure for a 70+ people company and honestly I am struggling a bit with how to set it all up. Basically what I am lacking is the third layer of in the hierarchy and I just can't decide how to solve it.

For argument's sake let's say my team is concerned with development regarding product A. Most of our capability is within frontend development though, so we often need help from service teams (UX, backend, mobile apps etc.) to finalize the delivery. Now I could do this:

• EPIC: Large project such as new landing page (months)
• Story: All the features that go int an EPIC such as create new banner, new navigation, new content area etc. etc. (days to weeks)
• Task (not subtask): All the smaller components of a story related to different teams e.g. UX, Frontend, Apps, backend etc. (day to days)

Because I use tasks I now have to manually LINK all tasks to their respective story which is a major hassle to be honest... One could say "well use subtasks then" but that creates two issues:

1. All of the teams (UX, Frontend, Apps, backend etc) are using different Jira-projects and subtasks can only refer to a parent in the same project
2. Requires that I may drag all subtasks into a certain sprint since subtasks aren't visible in the backlog-view of a scrumboard

Now one possible solution would be to shift everything upwards, i.e. use Epics as Stories above and stories as tasks, but that would however imply some other drawbacks:

• Alot of Epics with in the project with maybe 3-4 tasks per Epic
• Putting in a placeholder Epic doesn't show in the backlog view of a scrumboard, hence hard to see items "up for grooming"
• There is no "larger initiative"-type, maybe one could use versions? I don't know, it could work but doesn't really do the job (versions aren't very visible, hard to get an overview picture)

At the moment I feel lik there is no optimal setup, but then I think "this problem must be extremely common, someone must have thought of a better solution" - well is there?

Thanks alot guys!

[mike Kinloch]

Hi Christian,

Your right.  there are probably a number of ways you could solve this.  What you describe isn't normally the biggest problem people have an issue with.  It's normally'How do we re-use Stories for our product with other teams.

Anyway, let me give you an example of how we have set ours up to see if that helps you.  I think it matches with the way you already have yours working.

We have:

• A product which is built up of multiple solutions and developed by multiple product teams. 
• A number of customer-facing teams who deliver the product (take the product, customize it, maybe build some bespoke features) to our clients.

We have kept the structure as simple as possible.  In order to do this we haven;t created any new issue types\hierarchies in Jira.  This enables us to keep the system performant but also means that as we hire new people we don't need to train them too much on a customized approach.

Essentially we have pretty much what you described (and believe me when I tell you I have tried many, many different approaches).  The structure is this

• Version\s (one or more to track a release\s for a project or product team)
• Epic\s (to track features we are going to build.  Obviously these can be quite large in size)
• Stories (These are our business value.  Including acceptance criteria and meeting INVEST principles)
• Tasks (More technical in nature.  These are a maximum of 1 or 2 days in size.  These are linked to Stories)
• Sub-tasks (Under Tasks to plan exactly what needs to be done in more detail)

Our Tasks are used by the teams and are created during refinement.  It enables our Stories to stay intact and keep the business value while the tasks can be split down by the teams any way they like, giving them full control to work as they wish.  The team might split by screen section, data, etc, etc.  This also adds another benefit.  As we don't split the stories down themselves we retain all the info in them and then those stories can be re-used across other customer projects.  The stories form our product documentation and our Intellectual Property.

Yes, it takes some additional effort to link Tasks to Stories but not a massive amount.  You can do this in Excel to speed it up and just import them.  Jira will merge any changes too.  It also keeps Jira in a standard format.

Visibilty wise we track the versions through the version report, but we also use Arsenale DataPlan reports plugin to show a nice graphical percentage complete for one or more versions.  This is a bar chart.

Again, we use Dataplane report to show progress per Epic (Feature) in a nice bar chart.

Stories don't move through our workflow really.  The teams move the Tasks through our workflow and then as a final step (once all related Tasks for a Story are complete) the team simple review the Story together and close it.  Stories just move from To Do -> Done.

Hope this helps.

If you have any other questions let me know.

Mike Kinloch

Head of Development

Intelligent Environments

[Christian Hultin]

Thanks Mike, it sounds very similar to what we have going here, and it seems like the best solution. Not optimal in my oppinion, it would be great if Jira could support another level in the hierarchy (out of the box) with simple linking such as EPICs, but I guess this is the next best proposal.

One thing I am curious about - how do you make it obvious which tasks are relating to what story? As of now I have to kind of keep them manually ordered in the SCRUM backlog-view (tasks underneath a story is related to that story), but it feels very manual. And like you mentioned, the storys rarely move themselves, which is OK I guess, but they can clutter the board a bit... 

thanks!

[mike Kinloch]

orrectlyYes, it's annoying, isn't it!!  You do end up with Stories and then the tasks below them in an ordered fashion.  I haven't found a better way to get a nice view yet.  I've tried a number of plugins one of which being ScriptRunner but no Joy yet.

There must be a way to hack it and I will find it in the end!

You can just add a filter to the board to hide the stories while in the sprint and then re-show them whenever you want.  Again not ideal but removes the clutter when you want to.

Many people will suggest using sub-tasks instead of tasks as you get the hierarchy.  That works if you use 'Original Estimate' for estimating rather than Story Points as Jira will sum up the Sub Task time for a Story.  I use original estimate but don't do this as I still don't think it fits the model correctly as I want to keep sub tasks for the very low level planning.

[Elizabeth Kelleher]

The Parent Link feature of more recent versions of JIRA could be helpful here, but still requires manually linking children to their parents. It will however, give you a section within the Story where all of the Tasks linked to a Story can be displayed as children of the Story, though this will be separate from the sub-task view.

Otherwise, I agree that a plug-in such as Structure, or investing in Portfolio for JIRA will allow for additional levels.

In some ways, I miss "classic JIRA" for this reason - before Atlassian fully incorporated Greenhopper into the product, one had the ability to create an unlimited number of levels of Epics. An Epic could be a child of another Epic, you just had to name them carefully to distinguish them from each other. At one point, the organization I was working for actually had ALL of our agile projects stored in a single JIRA project, and we relied on the Epic hierarchy to split them out by product line, we had an "initiative" or "project" level below that, and then the standard Epic-Story-SubTask and Tasks were rarely used, but available, and different teams used them in different ways - often as blank placeholders in the backlog! After we got Greenhopper, we went back to having a project per product, and no longer had the unlimited Epic levels.

I think it would be a great feature to provide the ability to build a custom issue type hierarchy out of the box, with JIRA Software without having to purchase Portfolio or another add-on, but continue to provide the Epic-Story-SubTask hierarchy as a default template for getting started.

[Vanesa V. Vilas]

I do miss classic JIRA for this. I've been out of the JIRA admin roles for a while (being a mother) and now I'm back is all changed in this sense, I'm going bananas trying to create a hierarchy structure of issues for a software development project.

[Eugene Sokhransky _ALM Works_]

Hi Christian,

We make Structure app, which is designed to manage use cases similar to yours. Most of our customers go for option number 2. They would create a level above the Epics, by creating a new issue type (Initiative for example), or a special project. Many would also create a special link type to connect Initiatives to Epics and reserve it for this purpose only. Then you can use native functionality of the Scrum boards for day-to-day work on Epics and Stories, and use a separate Kanban board for the Initiatives.

The biggest disadvantage here is that there is no way to see the entire hierarchy in Jira out of the box, but you have the same problem with the first option - you'll either end up seeing Stories and Tasks in a single list in the Scrum board, or you'll need to create separate boards for different views (or use Saved Filters).

With Structure you can create overviews of the entire project, calculate progress and all other metrics you might need, based on the hierarchy you create.

Here is an example of such a hierarchy: https://demo-structure.almworks.com/secure/StructureBoard.jspa?p=1261623799&os_username=demo&os_password=demo#

I hope this helps.

Regards,

Eugene (ALM Works)

[Sara_Hicks]

Sounds like you can do it any way you want. I'm going to propose to my team (building application A) that we use epics, then stories with subtasks, and tasks do not get subtasks, but are items that stand alone. anyone see a problem with that?

sara

[Nicolas Seronvalle]

Hi, 

Why do you say that when working with stories and tasks you will have to manually link ALL tickets? When you will create a task, will it refer to so many tickets? If so, Why not linking it to the epic then?

When using subtasks, if you have to make a piece of work in another project you can create an issue in this project and link it to the subtask.
When you put a story into a sprint, it brings with it all the subtasks. Because when you begin a piece of work, the goal is to finish it by the end of the sprint :-)

[Thomas Schlegel]

Hi Christian,

I think that your tasks are not the way, we use tasks. A task in my opinion belongs to a single user story. The backlog is based on user stories only, so their story points are summing up the effort of all their subtasks (but of course, in Jira the subtasks don't have story points). As you said, a subtask is something that should be done in one day at the best. That's why we don't want them in the backlog. Soon, it would get big, overcrowded and not clear anymore.

A subtask is tied to its parent issue. Do you really need subtasks with two different parents? Why? Maybe you don't need so much projects, but more components in one project? Components could be something like UX, Frontend, Apps, etc. An issue could belong to more than one component.

Hope you get some new ideas from this.

[Christian Hultin]

Think you misunderstood my point, sorry if I was unclear - but a tasks will only be linked to one story in my setup. However since it is not a sub-task but just a task (which is on the same hierarchal level as Stories) I have to manually create the links...

I agree with you thought, maybe it is not great to have all tasks in the backlog since it will be crowded, but then again - if I want to prioritise the next two weeks I would likely want to do it on task level :/

[Thomas Schlegel]

Maybe we have lighter stories here :-)

For our sprint-planning, stories are sufficient.