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:
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.
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.
