Keep JIRA up to date as your org changes
Updated: Dec 3, 2018
Many companies have been using JIRA for many years and over this time, the way you work together has been changing and adapting and organisational charts have changed. So you hav been modifying JIRA itself (workflows, fields, etc) as workflows and communication paths have changed.
JIRA supports many parts of the the organisation. Your existing JIRA architectures has changed due to company history and evolving culture. Is your JIRA architecture still meeting your needs?
Periodically, its worth checking your JIRA architecture is still on a solid foundation. Here is a checklist of things to review periodically:
Do you know who is in each team and can they can see what they need to see? Typically this is done using filters, team dashboards that give them their own view of their team’s work. Typically, to keep information visible, technical teams can get access to all dashboards so can view others’ work or can be members of several teams at once.Is your glossary set up and up to date? ie what is a project? What is done?Do your software releases have named by Versions? This allows precise discussions about what issues are in what version and when they will get released. The affectedVersion is the release the issue was found in; fixVersion is the release this issue is destined for.Does the commit message contain at least one JIRA issue number, for example "ABC-1"Does issue has exactly one "assignee" or is unassigned, and one tester and one developer officially associated with it?Do you still have a consistent defined relationship between a JIRA project and a repo?Once Issues are closed, do they stay closed? If not, summary stats and find/fix charts can be misleading. If re-open needed, clone the rejected one. Issues are not deleted.Are manual changes to issues automated as much as possible? For example, when “landing” of branches occurs, the JIRA workflow can automatically update the “fix version” in JIRA to correspond to the branch it is now merged into.Are branches of completed work closed?Do JIRA dashboards show the right information to the right people? For example:Developers & dev manager see what they need to manage source, source control and builds.Project managers view project status in their own terms and wordsIs JIRA correctly mapping these different views ( project management, manager, dev) together? ( use "done" as an example, is a development issue "done" when testing is done?Does JIRA enforce or at least make visible a globally accepted definition of "done"?How are branches mapped to JIRA? Are your issues types still defining types of work that make sense both to branch strategy, your project management, and your development management? Examples:A feature is a major piece of work specified by project manager. (If the development takes place over several releases, an “Epic” may be more appropriate). A feature is on its own branch. A Feature is owned by one developer. All work to accomplish this feature is tracked in “sub-bugs” or “sub-tasks” under the feature. The branch name corresponds to the JIRA version number.Bugs are developed and resolved on their own branch.“Technical Debt” or “major rework” can be tracked in their own issue type. This allows the dev manager to valve the amount of rework done per release ( very useful especially if the dev manager is managing queues in a Kanban model)Tasks are pieces of work that involve NO changes to code or git.Do you find you have orphaned issues, ie ones that have somehow disappeared from everyone's dashboards/filters? If so, how can you make these visible?Does the whole organisation still have a common picture of how JIRA works? The most successful implementations of JIRA, I have observed, implement a JIRA architecture that is understood by the whole organisation and this can be described in a single picture or page.How are changes made to JIRA to ensure JIRA architecture integrity? Best practice is now to have a JIRA architect (or a JIRA team) that manages consistency of the JIRA system as it grows. This consistency allows global level metrics and supports coordination among groups as the company grows and collaboration among groups increases.Do you have a review and post mortem process to ensure that JIRA continues to meet your organisation needs in terms ofoverhead to update ticketssimplicitycompleteness ( ie do staff report they are tracking issues, spreadsheets, data "on the side" because JIRA is not doing the job for them?)capturing feedback about JIRAaccuracy of reportstimeliness of reportscontrol
Further reading
Managing complex projects with JIRAWhat to do when JIRA gets overgrown Keeping your tools simple Maintaining trust in your JIRA system Aranzgeo - a Kanban migration to JIRA Why to upgrade your bug tracking system Characteristics of excellent software tools
