Jira Software best practices provide insights in order to succeed on the implementation of the tool, on this case you'll find advises you should have in mind throughout the process of implementing Jira Software.

Steps to achieve a successful implementation of Jira Software

1. Keep the number of states, issue types, fields, to the bare minimum.
2. Jira is not MS Project.
3. Don’t lock down your configuration.
4. Trust users.
5. Predict the adoption complexity of your workflows before starting the implementation.
6. Extra tip according to our experience in DEISER.

In Jira Software, there’re not unbreakable rules. Here you'll find 5 aspects that should be wise to avoid when your team is about to adopt Jira. The list is mostly based in real experiences with customers of all sizes who had very different processes they wanted to run on Jira.

1. Keep the number of states, issue types, fields, to the bare minimum

What you really need is to track tasks, bugs or issues (the name doesn’t matter) so you have a series of metrics and reports that provide credible information and offer a true image of your team. Again, it doesn’t matter whether you are on development, support, or anything else.

Beware! This doesn’t mean that you can’t create big processes on Jira. You can, but if you have a team of 3 to:

•    Report a bug.
•    Fix it.
•    Report on the current situation.
•    Notify the client with any missing info.
•    Test.
•    Take the fix to the production environment.
•    And hundreds of other tasks!

It sounds like a lot, right? That means you should make the use of Jira as light as possible. Your team has enough on its plate as it is, they don’t need to have a tracking bureaucracy on top of that!

On the other side, if you have different teams for each of the above, go ahead! Create states to monitor every detail in the life of your issues and use Jira to capture different types of tasks. The work of each team would be limited to their “participation frame”. Ultimately, you should measure what makes sense and not overload nor micromanage. Processes should be a support, not an unsurpassed wall.

If we take business processes for the Holy Grail, we will undermine their mission. And then we’ll have to call an innovation consultant to demolish them, very much like the teacher in “Dead Poets Society” teaches to criticize doubtful methods to rate poetry. I couldn’t agree more with this video!

2. Jira is not MS Project
It’s neither better nor worse: it’s different.

Don’t try to simulate on Jira what you’d do with Project. Every time you think again of “monitoring the project with Gantt” remember that:

•    Work assignments in Jira are granular: you assign an issue or a sub-task to a person. So forget about making team wide assignments: you can make reference to teams, but you can’t pull stats on assignations, load and actual effort.
  
  
•    Jira issues have a hierarchy on two levels: issues and sub-tasks. Sure, you can also link to other issues. If you need more, you’ll have to get an app from the Marketplace for it.
  For instance, Projectrak (formerly Profields) solves some of the functional limitations in Jira allowing to treat projects with a level of complexity that is similar to that of issues. Going back to the example above, one of the things that you can do with Projectrak is assign work to groups of people. 

How to effectively track Jira projects? >>

3. Don’t lock down your configuration

When designing custom workflows, schemes and screens, etc. think that the daily life of your company, department or team is much more important that any project management methodology or framework (it doesn’t matter whether it’s agile, waterfall or based on the reproduction of the codfish).

4. Trust users

Independently of the processes you create on Jira, listen to users. They will be the ones to facepalm or endorse what you’re doing. By now many of them will already have used Jira and can be of great help when it come to decide the details of your workflow.

5. Predict the adoption complexity of your workflows before starting the implementation

Jira is a tool you can easily set up if you can use the by default settings. However, under many circumstances advanced configurations are needed:

• Your workflows have exceptions.
• You manage projects with very different attributes.
• There’s involvement from other business areas.

Even if it requires more work, Jira can also cover these scenarios: contrarily to what Atlassian states, somewhat underwhelming the product, Jira is not only an issue & project tracker.

Jira supports multiple workflows (and I’m talking in a broader sense here, extending to data input and output, notifications, etc.). You will need two skills in your team to frame this:

•    The ability to define workflows.
•    The ability to implement the workflows in the tool.

Extra tip! Jira projects and our experience at DEISER

Don’t forget to always keep in mind that Jira was designed to manage issues within a project and to monitor those issues without looking at the broader management. To do that, you can complement the product with plugins like Projectrak which contribute to the project with smart and actionable information.