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; } } }

Jira Hierarchy best practice

Eran Malovany_h5o31q

Hi All,

I am trying to find the best practice to use Jira hierarchy and implement it as part of the ALM process.

What hierarchy are you using today? Epic -> Story -> subtasks ? or something different?

i found out people are using different definitions for each issue type...

assuming you do follow the hierarchy i mentioned above, what your development board is presenting, Stories or subtasks?

i am trying to find the optimal solution for one jira project with multiple development teams, to cover also a case a feature can be handle by multiple teams...

WDYT , any thoughts

Thanks you for your input

Comments

Karen Lewis_oq541d

Hi Eran!
Some random thoughts from me.

I work to Theme, Feature, Epic, Story, Task, Sub-task, but I've come across a few organisations that swap Epic and Feature in that sequence.

Difficulties I've found are Feature tickets tend to go stale in the Backlog, or are moved onto a Board and sit there for ages because their children tickets are actually the tickets the team works on. This can distort reporting on progress, depending on how you measure progress.

Re multiple development teams, my current organisation sets up multiple Kanban boards within a single project and uses filters to determine what tickets appear on each Board. Again, this can bring its own headaches for the Scrum Master. Personally, I prefer separate projects, but again it depends on interdependencies etc.

I hope these thoughts help get the chat going.

Good luck!

Karen Lewis

Eran Malovany_h5o31q

HI Karen,

Thanks for your feedback!

So regarding issues like epics and feature sitting of different board, there is a way to automate the transition to the relevant board column based on your workflow using automation for Jira, used it in the past, really good tool.

i have a question specifically regarding the day to day work your engineering does, and present on their daily board, let's assume the development board, what issue type you presents using the filter?

Do they work on stories / tasks or Subtasks? assuming only US & Tasks appears on the backlog, how you split a story with multiple sub tasks across multiple teams board?

and how you define each one of your issue types: Theme, Feature, Epic, Story, Task, Sub-task

Thanks

Lou

Hello Eran,

We are in the process of fully implementing Jira's OKRs into a hierarchy based Atlassian's Guide, as these were already being developed by the business for its overall strategy.

In summary OKRs enable your business's senior management to define its strategic objectives, define the programmes/projects to deliver the objectives, define and breakdown to appropriate level of detail your business needs at the various role/job levels.

Strategic Themes (OKRs) > Initiatives (Programmes) > Epics (Projects) > Stories (highest level dev issue) > Tasks (lowest level dev issue) - Sub-tasks (are used at any of the previously mentioned hierarchy levels as checklists). This approach enables you to use your chosen Agile approach(s) (DSDM, Scrum, Kanban, etc), while still being able to satisfy business wide requirements.

We've setup ours as follows:

Strategic themes are managed within a dedicated project managed by our senior management team.
Initiatives & Epics are jointly managed by project management & product owners within a dedicated product project (where the project backlog developed ready for our development teams).
Stories are created within our product project, then later duplicated/moved into the development team project sprint/kanban backlogs when ready.
Tasks are created by the development teams as and when they want to break down stories to share out the workload across the team.

In the past I have seen a single project being used by various teams and while it can work well. The one question you have to ask is, how many teams are you expecting to use the one project? As the more teams you have, the increased likelihood the one project could become unsuitable for tracking all the teams work. Here's a few of reasons why, that initially spring into my mind even though there are many more considerations:

Different teams work better in different ways depending on their activities, and you only need to consider what the Agile software development manifesto says about this "Individuals and interactions over processes and tools" to remember why this might become a potential issue.
Managing/monitoring all teams under one project is harder under one project than when each dev team has it's own project, although not every team needs their own project such as your QA team. Also projects can use the same workflows when appropriate, and using the Advanced Jira Workflow plug Karen mentioned will enable you to define the differences each team might need to customise its use. As well as other plugins like JQL Search Extensions to really take your team/role boards to the next level (although not required if you simply want to pull multiple projects onto the same board).
Scalability, both as your team members growth and the number of teams grow, will the one project be the most efficient way to manage issues as you scale everything up. My one golden rule here is think large and scale down. Don't design and then scale up! As scaling down an idea/process is far more simpler scaling them up.

Hope this helps

James

Eran Malovany_h5o31q

Thanks @Lou for your detailed feedback!
I totally agree with you, multiple Jira projects are better to managed and this is the way i use to manage in previous companies, project per product group, while product group can sometime have more than one team.

We are a small startup trying to reduce cost and prefer to use the standard version of JIra and not upgrade to Premium. Using one Jira project i can use automation for Jira which is really powerful tool, i used it in the past to automate big part of our workflows.

i guess in the future based on company growth we will upgrade to premium and use multiple projects.

One more question, regarding the hierarchy you mention above, stories owned by product and developers using tasks...
Are you just linking the tasks to the Story? (since there is no parent connection between the two). and from jira perspective both on the same level.
any issues you are experience with that? (Pros VS Cons)

Thanks

Eran.

Lou

You're welcome @Eran Malovany

No, because we have premium, it comes with free access to Jira Advanced Roadmaps (JAR). This allows us to automatically state what is a parent of what, at what ever level of detail we wish to go down, or up to in our planning regardless of using two of the same issue type. All of which (the planning) can be done in the background to build a fully detailed plan, that fully takes into account each teams capacity, through us predefining each teams sprint velocity or available hours if planning for Kanban, etc. Best of all our management can thrash out the detail in their plans without disturbing each other and the teams working on issues. As they are only published once they're happy it's what everyone had agreed to delivering. Then once published, we just create (for the first time) different levels of the detailed plans based on the stakeholders needs that always updated from the main plans view, without having to create a whole new plan each time for the different stakeholder holder groups.

It's a very visual and one of the best planning tools I've used. However, one word of warning, it's easily the most complex planning tool I've had to setup and use with a business. So while I highly recommend it to technically skilled individuals, if your a slow starter or struggle in any way with new software, it's not one for the faint hearted.

Pro's to JAR

It can completely replace all your current planning and resourcing tools and rather than planning in another tool, then having to create it all in Jira once you've finished planning. This can publish it all in once go/place! Even the issues if not already created will be done/created as part of the publishing process, saving hours of time (easily self-funding the step up to premium just in this part alone).
Ease of linking issues to form quick plans forming a visually clear hierarchy
Splits out unassigned work from assigned/panned work
Realtime capacity planning with warnings, based on work in progress and timings
Clearly made with agile project planning in mind

Cons to JAR

You must have premium to use it (there's a 30 days free trial - Which I'd POC JAR to show the business it's ROI value if I were you)
Complex to setup and start out using - video walkthroughs and guides have been published by Atlassian, but they are very generic and require strong technical skills to properly grasp their concepts.
Doesn't automatically include internal events to include for your capacity planning e.g. for annual leave, training, etc. - Don't forget going down this route means you can set all this up in another project, because you'll have premium
Won't let you split the planning of a task without using multi tasks or sub tasks then using the roll-up feature to collate the time from the child tasks in the parent tasks. (just like MS Project really here)

Atlassian have definitely taken Jira to the next level with JAP, For me it's really an adaption of their old decommissioned Portfolio platform that did programme management... It seems they took that and made JAP for small to medium sized businesses, then have the even more expansive version of it that is the Align platform aimed toward Enterprise (Large/Corp) sized businesses.

Welcome!

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

Quick Links

Find more posts tagged with

jira

hierarchy