Jira concept mapping?

[Inna S]

Hi, 

we are in the process of learning Jira and setting it up for the large org.

Every day I come across confusing issues, types, management schemes and limitations.

Documentation is partial and you've got to look in several places to get a more or less complete picture. And then a limitation pops up at you in a totally unexpected place.

So I'm looking for a comprehensive mind-map describing the Jira features and components, their relations and limitations.

E.g. Team managed projects are cool, but you can't use them if you want Advanced Roadmaps, because they do not show items from the Team managed projects AND there is no way to filter out items from this kind of projects.

Or, the plethora of the user grouping means: Jira Team, Atlassian Team and directory Group.

You can filter by one, send notification to other, define access via third and assign to one of them, but only if you use Roadmaps.

Does anyone has the relevant info in a structured source?

Thank you,

Inna

[__ Jimi Wikman · Accepted solution]

Not that I am aware of.

Atlassian is suffering from snow globing and their products reflect that as well, unfortunately. I have written about this problem before here: https://atlasstic.com/articles/thoughts-opinions/jira-harder-to-control-jira-projects-slowly-becoming-less-collaborative-r8/

It is a good topic though, so maybe I will make a video about it later...

From my experience, you should ignore team based projects unless you want total freedom and no collaboration between Jira projects.

Timelines in Company managed projects only work with data from one Jira project so I rarely use that for that reason as well.

Teams mean nothing in Jira and if you want any way to use the term you probably want more than Jira offer anyway. Most setups either add a custom field for Teams or use a third party app like BigPicture when they need resource management.

I am building a playbook for Jira Software Cloud, so I will take this point of view into that, but for now I suggest you just as a ton of questions where you can't find the information on your own.

We are here to help you as best as we can.

[Inna S]

Thank you @__ Jimi Wikman !

Very insightful article and I'm definitely taking notes.

Here we are used having a work basket for every small group of people we call 'team'.

The 'team' has its own 'scrum', with scope planning and iterations.

I hoped to have a Jira project per larger group of people, all working on a 'product' or what is called 'product line' elsewhere.

Then I understand the 'board' is the way to go to scope the work for the 'team' of ours.

At this point I'm looking for the way to build the filter for this board. 

Been a bit spoiled by the decent tools in my career, I'm at lost with the Jira take on basically everything. It looks so raw-cooked and chaotic that I can't understand how come they have that many customers.

[__ Jimi Wikman]

Happy to help :)

I often start by creating one Jira project and one Confluence space for each system. This is the Operational basis and this way you can connect system documentation with system work. If a system have multiple teams, then I create a board for each, or use a filter to make sure that each team can see what is assigned to them.

Then I add the Project levels so each project (which is a temporary work form) also have its own Jira project and Confluence space. The difference is that all user stories are pushed to the system projects using a custom field. This way you can have the same story in two projects at the same time.

I also create business areas, which are the strategic areas that have their annual budgets with the same setup as for projects.

I also tend to set up a portfolio level that connect all of these all the way up to strategic level.

I have a whole series of videos planned for this where I will show exactly how I configure this and how it works. I call it the flexible Atlassian Setup as it will work for all way of working ranging from Scrum to Waterfall and SAFe.

Jira is pretty straight forward as soon as you start to understand how things hang together and where you go to change what. Just hang in there and I am sure you will love it eventually :)

[Inna S]

It looks like you are describing the use of some ad-on, right?

I'm still not sure what is the best way to designate a team in Jira, so it could be later used for filtering towards the board. 

And I do not see the project level anywhere.

Trying to avoid the customization and 3rd-parties, for several reasons. But I'm ok to use both when justified.

[__ Jimi Wikman]

No add-ons in this setup, just configuration of Jira and Confluence :)

In the series, I will point out a few add-ons that could take the setup further, but you will be fine with just Jira and Confluence.

Do you have many teams that work on the same systems, or teams that work on several systems? If you do, then just start with creating Jira projects for each team first and see if that works. You can always move things around later if you need to.

Jira is built from a Scrum and Kanban point of view, so you will find it lack pretty much all collaboration and management tools needed for project management or portfolio management beyond those two frameworks. Fortunately, Jira is flexible, and you can build those things yourself with configuration and structure.

[Inna S]

We basically have teams of teams for 'verticals' and then cross-portfolio service teams, like tech writers, UI/UX and the like.
I do not like the idea of moving things between projects because Jira somehow thinks it is ok to change the issue key with every move. It is such a horrible idea when you have an item that goes back and forth between the RnD teams, I'm trying to avoid it by all means.
Definitely looking forward to the release of your playbook!