Newbie confused by hierarchy!

[David Hay]

Apologies for another newbie question...

I'm moving over to a company-managed software project, and am confused which hierarchy structure to use.

I assumed that we would just use Epic -> Story -> Task -> Sub-Task, however apparently that's not possible?!

I'm also super-confused that a SubTask does not support point estimates?

I don't remember any of this when we used Jira previously (although we had scrum masters setting everything up).

Please could someone advise on the best hierarchy to use that utilizes the Jira capabilities for point estimates, scrumban, etc..

[John Funk]

Hi David,

Jira has implemented a standard Agile hierarchy for those work types. Story and Task sit at the same level. Sub-tasks can be either under a Story or under a Task. Estimation is not typically done at the Sub-task level - that's way down in the weeds. 

[Trudy Claspill]

Hello @David Hay 

Adding to this:

The default work item hierarchy is Jira is

Level 1: Epics
|-- Level 0: "standard" work item types (i.e. Story, Task, Bug)
    |-- Level -1: subtask work item types

The work item types at Level 0 are the ones where you set Story points. These are the items count towards burn down/up charts and reports.

The work item types at Level -1 are not stand-alone work items. They can only be created under a Level 0 item. While Level -1 items can have their own workflow, they are generally considered to be work that is not deliverable separately from the parent item from Level 0. They are simply a method to break down the work of the Level 0 item for finer granularity. Level -1 items do not contribute directly to burn down/up reports. And for a Level 0 item to be considered Completed in a Sprint, all its child Level -1 items must also be complete.

You may find some benefit in exploring the free, on-demand training available from the Learning link at the top of the Community pages. Here, for instance, is a search for topics related to agile methodologies and the use of Jira.

https://community.atlassian.com/learning/catalog?product=Jira&search=agile

[David Nickell]

BTW -- having just re-read everything let me offer to more thoughts:

You can control the hierarchy of a Company Managed project (though it impacts all company managed projects when you make a change.)  See the attached Admin Screen Shot.

Also - I think @Trudy Claspill probably has it correct regarding behavior, but you might try adding the Story Point Estimate field to your subtask to see what happens.   As an Alternative, you can use a creative issue link type to associate a story to another related "level 0" task and use the story point field there.  

[David Nickell]

@David Hay  Your question has inspired me :-)....  and @John Funk  and @Trudy Claspill    your comments were very helpful. 

I was working on a configuration summary report yesterday and I compared Issue Types from COMPANY managed to TEAM managed projects, I was stunned to realize how much I didn't know before now.

In the screenshot below you will find issue types by name along with an ID and count of projects using that specific type.  In the column labeled software_company  (aka classic) you will notice those issue types are reused. In the column lableled software_team, the issue types are unique per project.

I am familiar with "classic"/Company Managed configurations and the use of schemes (issue types, field configurations, etc).  I need to do some investigation to better understand the handling of issue types and fields for Software Managed projects.  I don't know why, but I am concerned about the idea of unique Issue Types per project. 

I also know that most of the projects I have worked on over the years have utilized an Initiative as a collection of Epics.  This addition to the hierarchy isn't available in Team Managed Projects. 

Thanks for the "Newbie" Question. I may post an article later today or this week describing any discoveries I make.

[Trudy Claspill]

Hello @David Nickell 

The design of Team-managed spaces is based on the concept that the elements defined within it are unique to that space and not impactful to other spaces. It is intentional that the issue types in TM project have unique IDs even if their names are identical to issue types used elsewhere. The same is true for Status values in the workflows and Custom Fields that created within TM projects.

And yes, it is documented that there are limitations on modifying the hierarchy of issue types in the TM project. It cannot have more than one Subtask type work item and you cannot add levels to the hierarchy above Epic. Adding levels above Epic is available only in Premium and Enterprise subscriptions. and is still not possible for TM projects in that case. In that scenario the levels are added to the Global Work Item Hierarchy, and issues of those higher level types must be created in Company Managed projects. The Epics from the TM projects can then be made children of the higher level work item in the CM project. That is specified in the Atlassian documentation.

You can find reference material about some of the differences between TM and CM project in the Atlassian documentation and in the Learning center (link at the top of the Community pages.

https://support.atlassian.com/jira-software-cloud/docs/learn-the-basics-of-team-managed-projects/

https://community.atlassian.com/forums/App-Central-articles/Team-managed-and-company-managed-projects-in-Jira-Choosing-the/ba-p/2368866

https://community.atlassian.com/learning/lesson/configure-work-types-fields-and-layouts-in-team-managed-projects

[John Funk]

Friends don't let friends create Team-managed projects. There, I said it!

[David Nickell]

lol -- but it's so easy to click a template and hope for the best.  

[John Funk]

Yeah, it's like "want some candy little boy???"