Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Portfolio docs say create an Initiative type but isn't that just a dumb index?

I'm trying to adapt to the new portfolio (2?) strategy for gathering epics and stories into initiatives.

Previously, the advice was to create an 'initiatives project' so that the initiative instances were 'activities' in a project. That was hokey at best.

Now 'they' say create a new issue type. If I do that, the initiative type will belong to the 'default issue scheme', unless I attach it to an issue scheme assigned to a project.

That sounds like just another way to add an initiative to a project, or to the 'no project' project.

What's the concept for Initiatives and Themes that makes them an actual new hierarchy with their own behaviors and scopes, and not just a dumb index?

Thanks,

2 answers

Hi Kimball,

 

I'm still a bit fixated on this part:

Now 'they' say create a new issue type. If I do that, the initiative type will belong to the 'default issue scheme', unless I attach it to an issue scheme assigned to a project.

 

The default Issue Type Scheme will at all times contain all Issue Types that exist on your instance. When instances grow, it is likely you may be asked to create XY different Issue Types (and honestly, a lot of teams think they need them but they really don't). The bottom line is, you will eventually end up having more Issue Types the more your instance grows.

 

That said, it is actually not a good practice to be using the default issue type scheme - rather, I would advice having a few more standardized schemes that can then be re-used in different projects. If there is a project needing a custom setup, then it should be a separate Issue Type Scheme.

 

Having said that, I wouldn't put much focus on the default issue type scheme, it should not in the long run be used under ideal situation, and it is relatively easy to replace.

 

 

What's the concept for Initiatives and Themes that makes them an actual new hierarchy with their own behaviors and scopes, and not just a dumb index?

 

I'm not a Portfolio expert, but both Initiatives and Themes are just purely used by Portfolio. I do understand the confusion about it being classified as a "standard issue type", however that is how JIRA Software is built, and Portfolio has to work with the underlying structure as it is a plugin on top of JSW.

If you have a need for the Initiative level, it's more than likely you might as well be using multiple projects in the same plan. Regardless of that, Initiatives are easier to be handled in a separate project, because it will allow you to utilize their purpose in Portfolio, and they will not be getting in the way in the actual "work to be done here" projects because they're simply not needed there for any specific reason.

 

You can put Initiatives in the same project as your current one, but you might want to filter around it so it won't turn up in filter queries or boards, hence having a separate project for Initiatives is just more practical.

 

As for Themes - I was under the impression this is not an Issue Type but rather a feature of it's own accessible directly in Portfolio Plans. (https://confluence.atlassian.com/jiraportfolioserver/creating-and-configuring-themes-779170278.html - uh, can't find a cloud-version of the page but they should be roughly the same if we're talking concepts)

 

Hope this helps,

 

Regards,

Radek

Until Atlassian begins requiring their support teams to actually attempt to perform the real-life operations necessary for implementing real-life projects that matter to users, and simultaneously require that they compare their detailed experience to the content of their (always) abridged descriptions of how to use the products found as presented in the documentation, there is no value in a community support feature: because no users can have an accurate understanding for anything but the most obvious use case, which is never the situation in a support scenario.

The only complete, accurate, and detailed explanations of Jira product features I have ever experienced have been the result of clawing past the push-back from the support teams and actually having a discussion with tier 2 or 3 technicians in the Atlassian development or operation teams.

Otherwise, I invariably have to give up and go back to puzzling over the ambiguous, incomplete, fantasies they compose and call documentation.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Advanced Roadmaps

3 short videos to help you get started with Advanced Roadmaps

Hi community, I’m Roi, a product manager working on Advanced Roadmaps for Jira. While Advanced Roadmaps is a powerful tool to plan and track work at scale, we know it can be challenging to get star...

6,457 views 24 18
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you