Couple that with individual sprint versions and we have a workable system for multi-scrum, multi-sprint projects.

I think the ranking field should be used by the client to rank order the stories and then you use the priority field to order the tasks (critical, major, minor).

The Must Dos are what are on your sprint backlog and taken from the product backlog. Usually in the order of the ranking given by the product owner.

Because Jira lacks versioning per component, you have to use a project per versionable component – many applications are not discrete and have dependencies on other internal components. As such component is therefore largely redundant and in my opinion better used to “tag” issues into one or more categories.

Being able to fix these is useful in an issue tracking environment because in reality a lot of the users to not understand what tags to use if they are not shown the tags they can choose from.

I’m also a hardcore JIRA user and evangelist in my company. I tend not to agree with what you have written here. Using components to support other way of prioritization or so-called client-side prioritization (how important is this feature for the client) is generally ok, but renaming them to ‘tags’ is a little bit of exaggeration.

Tags (folksonomy) are defined as collaboratively defined vocabulary of keyword, while your approach is really to create another taxonomy (controlled vocabulary) that client can use to prioritize items from his side.

Going back to real tags, I found Label plugin very useful in JIRA. We use labelling for example to mark cross projects issues that are somehow related to some separate development spanning many projects/platforms. Before we installed Label plugin there was no logical way how to group those issues together apart from linking them, which is then very cumbersome when it comes to seeing all the issues related, and not only the nearest one.