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

[Kimball Johnson]

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,

[Radek Dostál]

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

[Kimball Johnson]

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.