Jira best practice for highly productive Agile teams
Jira is an extremely flexible tool and allows for extensive configuration. But as Uncle Ben once said in Spiderman – “with great power comes great responsibility”. This is where our Jira best practices guide focuses.
Jira is an enabler of collaboration, not an enforcer of process.
This is very apt when setting up and configuring Jira. You may be tempted to wield the power Jira provides and attempt an Agile transformation through locked-down workflows, standard templates, and providing a one-sized solution that fits all.
In the world of software development at scale, one size never fits all. A one size fits all is your fast-track ticket to failure.
This article will talk about the principles you should adopt when configuring Jira to enable Agility, not constrain it. It will give advice on how to give teams more freedom whilst preventing Jira from getting all messy and unmanageable.
Jira Best Practices for Setting up Jira Projects Correctly
Jira organises your work with Projects. Jira Projects are often used to represent static, cross-functional teams in organisations, who work together towards a common goal like building and maintaining a product. In this article, we use the terms project and teams interchangeably.
Over long periods of time, we find the list of projects in Jira grows and is littered with project names such as “test project”, “test1”, “tmp sandbox”, and so on. It is important to establish a naming convention for project names in order to make it easier to find the right project. For example, “Business Unit-Team Name.”
Regular housekeeping of projects is important to keep on top of your administration.
Only Admins should be able to create new projects in Jira. This is to ensure all of the Jira best practices and defaults mentioned in the rest of this article are set up correctly, including ensuring the correct permissions are applied.
Warning! Avoid using the NextGen projects type! Use the classic project type. At the time of writing, the NextGen project type is too immature in its capabilities when compared to the Classic project type. Atlassian continues developing the NextGen capabilities but is far from meeting feature parity with the Classic project types. As such we wouldn’t recommend the use of it – yet.
Jira Best practices for managing Workflows
Create a separate workflow for each team. Avoid sharing workflows between teams.
Always keep your workflows really simple.
You can certainly use a starter template to get them going with a sensible starting point. The team will have their own ideas on how to do things and make improvements, which will require tweaks and changes to the workflow and process.
It would be sensible to come up with a workflow naming convention so you can quickly and easily find team workflows. An example might be BusinessUnit-TeamName-SoftwareDevelopmentWorkflow
It is important to avoid having a different workflow for each issue type. In most cases, we tend to create a single workflow for work items at the story level (include Tasks and Bugs in this). Avoid multi-level workflows whereby all child work items must be completed before parent work items can progress to the next step in the workflow.
Allow all issue types to move to all statuses. Basically, allow drag and drop anywhere on the board.
Statuses – can quickly get out of control if not managed correctly. Introduce a change control process for this.
Ensure Grey, Green, and Blue states are allocated correctly. This is key to the out-of-the-box reports working.
Transitions – keep them simple. In our experience, allowing all work items to transition to all states is better.
Resolutions – don’t confuse resolution with status. Ensure Resolved date-time stamps are set correctly for each workflow.
Managing Custom Fields
Our Jira best practices recommendation is to introduce a change control process for this. Without centralised ownership of this, you will no doubt end up with many similar-sounding custom fields serving the same purpose. It will also help you avoid duplicating fields and prevent errors from occurring due to human error.
Jira Best practices for managing Boards
Boards should be created and managed by the team. As such, you need to ensure the settings on these boards will not restrict team members’ ability to modify their boards or cause confusion when they try to do so.
Ensure that teams can create and modify their own boards
Turn on the time-in-column indicator. This is off by default but it really is a useful feature that all teams should be aware of and use to improve the flow of value across the board.
Avoid using swimlanes to start with. Swimlanes tend to reduce the visual impact when visualising too much WIP.
Avoid using sub-tasks and especially avoid setting your board up with the Story as the swimlane and moving Sub-Tasks across the columns.
Keep the board at the story/task/bug level (see requirements hierarchy below). We often see teams with everything moving across the board including Epics and Sub-tasks. When your requirements are organised in a hierarchy it is important from a tracking perspective to ensure you pick the correct level in the hierarchy to represent the flow of value.
Don’t visualise and move epics across the board. Epics are a grouping of child work items and are used to create structure in establishing a shared understanding of work scope. You can certainly set the status of Epics to To Do, Doing, or Done to give you a holistic view of progress but just don’t visualise them on the team’s board.
Use Work in Progress limits where possible. Too much WIP kills productivity. Agree on WIP limits for each column on your board and use the built-in WIP limits functionality in Jira to flag up when limits are exceeded. Jira doesn’t stop you from exceeding limits but rather uses a visual indicator to alert you to the exceeded limit. WIP limits don’t limit WIP, humans do!
Teams can have many boards in a project (and across projects) which is normal and often useful.
Requirements Hierarchy & Issue Types
This diagram demonstrates the common hierarchy of requirements that is necessary for most programmes of work. The four levels of work provide flexibility and the ability to meet the demands of a wide range of organisations. Initiative→Epic→(Story/Task/Bug)→Sub-Task
Create consistency across the entire organisation in terms of the requirements hierarchy and the issue types used.
Teams should not have the ability to add new issue types or change the requirements hierarchy themselves. Jira best practices suggest this activity should be centrally managed and subject to change control.
Manage bugs separately and link to stories if required.
Set up health check pages in Confluence for each team. These health check pages provide an instant overview of the integrity of your requirements hierarchy. It highlights orphaned Stories or orphaned Epics, easing overall housekeeping activities. Maintaining a clean requirements hierarchy provides a solid foundation for estimation, planning and tracking.
Who should have Admin rights in Jira?
It is always a good idea to have a number of people with admin rights across your organisation as it will help align your approach and maintain resilience with Jira support. For this reason, you should create a community of practice (CoP) for this group of people to develop Jira best practices for your organisation. The CoP should be composed of a team of people who take responsibility for making the decisions and taking action on Jira and Atlassian products.
Teams need to have permissions that both allow them to complete work within their projects, and also modify project settings for their project. Preventing them from doing this, especially if it’s something as simple as editing boards, is not only demotivating but will make your team feel like they’re not trusted.
If you have a number of Agile Coaches across your organisation then it often makes sense for them to have Admin rights to drive adoption and change across the teams.
Jira Security & User Management
Security in Jira is a massive topic and beyond the scope of this article. Please contact us directly for advice
Adding Jira Plug-ins from the Marketplace
Strict change control procedures should be wrapped around this. It can get very costly, very quickly.
Take the hassle out of managing Jira. Get in touch now and let us manage Jira for you.
