Speak to developers and testers who are starting to use Atlassian Jira Software to manage their agile projects and you’ll sense their excitement. Here is a tool that supports agile teams and is relatively easy to use whether they’re doing scrum, Kanban, or another project management process.
Jira has the functionality for both advanced and early-stage agile teams. It has screens to support managing the backlog as a separate activity from managing the sprint. The most important information can be customized for teams and individuals on dashboards. The out-of-the-box reporting is good enough to get most teams started managing their velocity, cycle times, and tracking releases and epics. It has strong integration with many other tools developers use, including Confluence and Git. When it doesn’t have the functionality required, there’s a marketplace to find additional capabilities and integrations.
What’s not to like about Jira?
Now talk to scrum masters, developers, engineers, and testers who have used Jira for several years and you’ll notice that some have lost their enthusiasm. For them, Jira—and aspects of their agile development process—may have grown in administrative complexity. These experienced agile practitioners and advanced Jira users would love to clean up both their agile practices and how they use Jira.
Here are some of the issues.
First, configuring and using the tool can become overbearing and complex as teams elect to use more capabilities and configurations. Jira enables organizations to customize fields, workflows, screens, issue types, and issue layouts at a project level and then share these configurations to multiple teams using schemes. It’s easy to get carried away and overengineer the configuration until what was once an easy-to-use tool becomes a laborious experience requiring too much data entry, too many clicks to get things done, or rituals to groom the backlog.
Advanced users can compensate by learning some of the quick keys and shortcuts. I regularly use shortcut keys such as “c” to create a new Jira issue, “a” to assign an issue to a team member, “l” to assign labels, and “?” if I need help finding a shortcut. If I’m creating a number of new Jira issues, I’ll preselect releases and epics on the backlog screen so that new issues automatically get assigned to them. If I have to make a large number of changes, I’ll search for issues and use the powerful bulk edit capabilities.
But some new Jira users may not invest the time to learn all the tricks. They’ll leave details out of their stories and take too much time to update Jira as required. Scrum masters loathe the idea of having to update Jira issues when their teammates fall behind.
In summary, some agile organizations and teams using Jira may have lost their way by making the process and tool configuration overly complex. But by avoiding these pitfalls and adjusting the configuration, leaders, managers, and users can find the tool useful again.
Avoid turning Jira into an accounting system
Jira should be used to enable team collaboration and capture critical information such as story requirements, team velocity, and status of releases, epics, and sprints.
Some teams benefit from breaking down issues such as user stories and tasks to subtasks. This is especially useful for teams who are technically less mature, geographically dispersed, or who require many different technical skills to fulfill stories. This breakdown of stories into subtasks is useful for these teams to communicate who’s doing what and in what order.
But it’s overkill for other teams who know their product, technology architecture, and teammates well. They can communicate their implementation approach at standups or use collaboration tools, including commenting on Jira issues, or messaging tools such as Slack, HipChat, or Google Hangouts Meet. Asking or requiring task breakdowns will frustrate more advanced developers.
Going one step further and requiring time tracking in Jira will frustrate developers and testers even more. There are better ways to capture complexity and effort on issues; asking agile teammates to clock in aggravates them. Agile teams would rather focus on improving their agile culture and mindsets rather than capturing detailed metrics of their time.
Lastly, it’s easy to get carried away configuring Jira issue workflow. Jira sets up a simple To Do, Doing, and Done workflow with the same swim lanes on the active sprint board. Some teams will add statuses to capture more statuses and transitions such as requirements written, designs added, estimations completed, and devops functions addressed. They may go one step further by restricting certain transitions and adding role-based rules to the workflow, or by creating different workflows by Jira issue type.
All that complexity looks good and appears necessary to those governing the agile process, but it is overbearing to those practicing agile. It can also lead to dysfunction when swim lanes are misaligned with the required status transitions.
The point is that if you overcomplicate the configuration and workflow, you’re more likely to have unhappy users.
Extend Jira capabilities without overcomplicating them
Sometimes I see people try to do too much with any tool, including Jira, which makes the daily work of active users a lot more difficult than it needs to be. Sometimes it’s better not to do these things at all; other times you can find simple workarounds or options to integrate with other tools.
One of my pet peeves with Jira is that it only supports a three-tiered hierarchy of epics, stories, and subtasks. Many groups want an added level to support features such as a parent to stories and child to epics. This allows epics to represent long-running enhancements while features capture one or more stories implemented in a single release or a few releases.
My preferred way of dealing with this is to ask teams to add a prefix when they fill in the issue summary. If the feature is “login” and the story is “enable forget password function” then the issue summary would be “login: enable forget password function.” Another option is to create a custom field to represent the feature name.
These are not perfect solutions and they may lead to data quality problems if users don’t know the feature names. But since feature development is bounded to work done in a handful of sprints, it’s a reasonable workaround to Jira missing this capability.
A related issue is trying to make Jira the perfect system for product and project portfolio managers. These teammates have to capture and manage strategies, initiatives, roadmaps, goals, key performance indicators, and other business artifacts that tell a story and communicate business-level status. Jira is not the tool for this, but Portfolio for Jira, Aha!, and other product management tools are. If product owners and managers are struggling to use Jira for their needs, consider looking at one of these tools that integrates the data from Jira Software.
When Jira’s reporting tools are no longer sufficient, consider moving Jira metrics to other databases and reporting tools. For example, you can use Tableau for more detailed velocity and burndown charts.
Lastly, advanced teams may want to standardize certain repetitive Jira tasks and stories. For recurring tasks that need to appear on the backlog according to a defined schedule, the Recurring Tasks for Jira Cloud application is available in the marketplace. For operational teams who need to add groups of templated tasks to the backlog for a specific job, I’ve used Quickbase to store the templated stories and transferred them to Jira using a Quickbase and Jira Zapier integration.
Jira is a highly versatile tool used by many agile teams, but it’s easy to overengineer data entry and workflow to the detriment of team collaboration. Like any other software tool, it’s best to bring advanced experts, novice users, and program administrators together to find implementations that provide the necessary governance and required collaboration.