top of page
Venduco

Blog site of  a volunteer activist

  • Writer's pictureIan Wells

Preventing JIRA overgrowth

Updated: Dec 3, 2018

JIRA is a great  tool for developing software. One reason its great is because its so configurable. But I continually hear stories of JIRA, over the years, growing out of control.


In a software development company, one way to tell if you have an overgrown  JIRA  is that you  can't get accurate reports from it. The numbers in your just don't match reality.


If your JIRA is overgrown, check your answers to these questions:


Do you have a defined  JIRA architecture?

JIRA, just like any other major software you use, has  an architecture. Can you draw a picture of your JIRA architecture on a single whiteboard that you can show to anyone in the company - and it makes sense? If you got people from all different roles who use JIRA, into the room at the same time, can you walk an example task or feature through that architecture from conception to customer release, and everyone in the room agrees?   If not, then its time to document that architecture and eliminate the parts that are inconsistent.


Are your workflow processes a force fit into JIRA?

JIRA is wonderfully configurable, but there are basic principles that improve the  fit between your development reality and the JIRA screens that everyone stares at. JIRA started its life as a software development and test tool. Recognizing this, Atlassian in 2015 bifurcated JIRA into JIRA Core and JIRA Software. The  object model in JIRA Software is the one that more closely matches software development. JIRA Core is a better fit for  non-software issue tracking and  management. JIRA Software itself is not a project management tool. So don't get confused by the term "project".  A JIRA Software "project" is a better fit for what software developers call a "product" in a single repo, ie the product has builds each with unique version numbers. Work ( issues) are done targeting a particular release.  I find the best fit is to map  a JIRA "project" object to something in your organisation that has "releases" with version numbers. A JIRA "project", like a software product, lives for a long time. Using JIRA "projects" this way, can help you reduce the number of JIRA projects in your organisation and makes it easier to  align JIRA with git branching. So JIRA can become overgrown by continual mismatches of the team's needs and JIRA. A place to start is to create a glossary and define "project"," definition of done", "version","component" etc


How does  your JIRA architecture support real-life non-tracked  workflows?

2 cases:

  1. The JIRA workflow doesn't cover what people really need so they followup tickets with conversation, email or SMS with additional vital information. This should be caught by your JIRA quality control. Fix workflows to make everyone's job easier.

  2. Overly prescriptive workflows encourage inefficient  behaviour. This is bureaucracy setting in. Effective  software development relies on people and communication before tools and tracking. Use JIRA to help communicate, but don't use it to make more work than necessary. Here are examples where you don't need to put everything in JIRA:

  • Use stickies and whiteboards if that is  more helpful than JIRA scrumboards.

  • Use standups to decide on work instead of assigning JIRA tasks blindly.

  • Testers and developers can find and fix bugs rapidly by  sitting down next to each other with no need to create JIRA bugs.


Who in your organisation  is in charge of JIRA quality?  JIRA is just like every other good software system. It needs to meet requirements,   changes must be tested; dependencies must be minimized, data types must be defined, feedback must be  in place to  continually reassess fit for purpose - in short,  someone is needed to manage JIRA quality. That person is someone who can drive decisions that ensure the integrity of the entire system and to continually ensure it  is fit for purpose.  If you don't have such a person, that could be a cause for overgrowth.

6 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

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

Home: Blog2

Subscribe

Home: GetSubscribers_Widget

Contact

Your details were sent successfully!

Magazines pile
Home: Contact
bottom of page