top of page

Blog site of  a volunteer activist

  • Writer's pictureIan Wells

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

17 views0 comments

Recent Posts

See All

Version numbers JIRA version numbers  correspond to the branching strategy being used: For example There are unique version numbers generated per build. These uniquely identify the executable but can

Home: Blog2


Home: GetSubscribers_Widget


Your details were sent successfully!

Magazines pile
Home: Contact
bottom of page