Jira Software best practices provide insights in order to succeed on the implementation of the tool, on this case you'll find advices you should have in mind throughout the process of implementing Jira Software, such as:
Keep the number of states, issue types, fields, to the bare minimum.
Jira is not MS Project.
Don’t lock down your configuration.
Predict the adoption complexity of your workflows before starting the implementation.
Extra tip according to our experience in DEISER.
In Jira Software, there’re not unbreakable rules. Here you'll find5 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.
Report on the current situation.
Notify the client with any missing info.
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 unsurpassable 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 simply 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 just 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, 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 Profields is assign work to groups of people.
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
Exta 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 Profields which contribute to the project with smart and actionable information.
And you? What other things should be avoided in your experience when it comes to implement Jira? What lessons have you learned?
Transform Jira into a project tracker
Follow the steps of our customers and build the projects of your dreams with Jira + Profields