Summary: An expert user of Jira, Carl Young sees businesses face the same issues all the time: they change how they do things to fit Jira, instead of making the tool work for them. Carl’s expert advice will help your teams avoid frustration by showing common mistakes when implementing Jira and how to use it successfully.
Make the Tool Work for You
When I am asked to help someone configure or troubleshoot their Jira setup, I usually see people snagged by the same pitfall: Users change their Way of Working (WoW) to fit Jira, rather than customizing Jira to fit their actual business processes.
As a result, Jira adoption suffers and sets the stage for failure. Users become frustrated with unfamiliar issue types, work patterns, and permissions because the default Jira setup doesn’t match how your organization actually operates. Once that negative first impression is set, it’s difficult for people to change their minds. Starting off on the right foot when implementing Jira will not only help you be successful through it’s features, but will better meet the needs of your team for smooth sailing.
Thanks to Jira’s flexibility, it is easy to make Jira work for you rather than your company working for Jira. In this blog post, you’ll get guidance on how to avoid common mistakes and amend Jira to suit your needs.
Note: Jira is a Software as a Service (SaaS) product from the Australian company Atlassian. Screens, features, and layout can change at any time as the product is enhanced. For example, Atlassian has rolled out a new product named Atlas. This article will focus on Jira since it is the most commonly used Atlassian product.
Choosing the Wrong Project Template
After you log in to Jira and click on Jira Software, you will see a dizzying array of templates in a gallery and links to your existing work. When you create a project and choose Software Development, you will see options for Kanban, Scrum, and other choices, which are explained in Jira documentation.
The first mistake users often make is to choose a project type that doesn’t fit their development methodology. Users will click Kanban (probably hoping they can escape a daily Scrum), and find themselves in a continuous integration and continuous delivery (CI/CD) development world with Work in Progress (WIP) limits. That’s great if that’s how your team works, but often software development work is performed in managed releases, so this template creates more problems than it does solutions.
Instead, in the Jira world the Scrum template is used for most Agile workflows outside of Kanban. For example, if you work in a Scaled Agile Framework (SAFe) shop. you would choose Scrum even though the issue types are different than the pure Scrum methodology from Scrum.org. You or your administrator will need to add SAFe issue types like Feature and Impediments. The key here is to select the project type that most closely matches your actual overall Way of Working and make tweaks as needed, instead of selecting one that has the right name.
Choosing the Wrong Management Option
The second mistake is choosing a team-managed project instead of a company-managed one. Team-managed projects are easy to use, but those projects exist in a cowboy domain without governance, consistency, and accountability. For example, teams can invent their own custom fields and workflows that will not show up in any other project. This creates a lack of uniformity, consistency, and control over how the project is managed and executed, while also limiting the integration with other projects or programs in the organization.
Jira is chosen by most organizations because they want teams to cooperate and would like to roll up individual projects into programs. The price for achieving this consistency is using a company-managed approach where most customization must be performed by a Jira administrator whose job is to set standards. This ensures any changes are evaluated for their impact across the board and are approached from a governance perspective. See the image below for more details on the differences between the two types:
Settling for the Defaults
The next mistake is to accept what the Jira administrator gives you, which will probably be the default settings. After all, the administrator likely does not know your WoW and wouldn’t know what alterations to make. There are several areas within Jira where customization may better suit your workflow.
1. Issue Types
The graphic below shows the default issue types:
These issue types can be used different ways, but here are my recommended definitions:
- Epic: An Epic is the highest-level issue in the project and is the parent of all stories, tasks, and bugs.
- Story: Short for User Story, which describes functionality that needs to be implemented. Stories can be assigned to developers, and they can have estimates and priorities.
- Task: Tasks are for non-functional requirements such as security, performance, and reliability. Just like stories, tasks can be assigned to individuals, and they can have due dates and priorities. Stories and tasks are often confused. For reporting purposes, it is advantageous to keep stories, which are usually in control of the development team, separate from tasks, which often are assigned to specialized departments outside of the team’s control.
- Bug: A bug is an error in the software that needs to be fixed. Bugs can be assigned to developers, and they can be assigned severities and priorities. You can use Jira Service Management to have testers log bugs and have those automatically appear in your project’s To Do bucket.
- Subtasks: Subtasks are children of Stories, Tasks, and Bugs. You can require that all subtasks be completed before its parent is marked as completed.
If your WoW requires other issue types or a different hierarchy, your administrator can make those changes to company-managed projects. For example, if your team thinks Epics should be rolled up into Features, your Jira admin can make Epics a child of a new issue named Features. Ultimately, your team should discuss how the setup of Jira would serve them best and work with the administrator to make that happen.
Workflows and fields are two other areas that your Jira administrator can assist with.
For a Scrum project, the default workflow looks like this:
While many software projects have been delivered with just these three states, your WoW probably looks something like this Jira sample:
Again, this is something your team should storyboard and ask the administrator to implement for you.
3. Layout and Fields
Lastly, I see too many teams accepting the default issue layout which looks like this:
Does the reporter really matter? What’s the difference between Story Points and Original Estimate? Most importantly, how can a developer, tester, or manager tell if this User Story is complete? Sure, someone can mark it Done, but is it really? Does it meet your team’s completion criteria, or readiness for QA?
Changing fields is simple (though you should contact your administrator if you need a custom field).
In Project Settings > Layout or Project Settings > Issue Types, you can control what fields appear when you create an issue. For example, if you don’t care who the Reporter is you can hide the field. By adding, hiding, and rearranging fields you can simplify the user view:
To monitor progress toward task completion you can create subtasks, or you can add a checklist:
Adopting and using Jira has numerous benefits, so long as you set yourself up for success with tailored workflows. You can avoid frustrating teams by spending some time up front to plan what you need out of Jira. Make the tool fit you, not the other way around. Follow the recommendations above and you will be in the top tier of Jira users.
Have a Jira Expert on Your Side with Tuck Consulting Group
Is your team in need of some finesse to make Jira fit their needs? Don’t have the time or capacity to learn how to tailor the product to your Way of Working? Carl and other experts at Tuck Consulting Group are here to get you running on even ground. Get your releases and projects on track with a tool that matches your Way of Working by booking a meeting with us here.
Carl Young, PMP
Senior Project Manager
As an expert administrator for Jira Work Management, Jira Software, Confluence, and Trello, Carl has extensive experience in the world of Agile, application development, and IT project management. He is a Professional Scrum Master and is Scrum Product Owner Certified, with experience ranging from government to healthcare arenas.