How to Make Developers Fall in Love Again With Tickets

Developers have a very strange relationship with tickets. If you ask them if they like the ticketing tool they use at their company, you will get completely different comments on the same tool, depending on the organization. For instance, the most used one – Jira – is rated 8.2 / 10 for more than 2,000 reviews. But if you ask teams if they are satisfied with the way tickets are handled in their organization for the same Jira users, the rating goes down to 6.3 / 10 and a Net Promoter Score (NPS) of -25!! And this on the set of 129 companies we surveyed at Anaxi. Just a reminder: a NPS score under 0 is very alarming for any company, so let’s not even consider -35! So how do we explain this? And how can organizations change this? That’s what we will try to answer in this article.

First, I suggest we look at the survey’s results, and deep dive into them to understand why developers rate the way tickets are handled in their organization so poorly.

Then I will share with you what was bothering the developers we interviewed the most after the survey (naturally, we wanted to know more!).

Finally, we’ll look at some companies and examples where developers love how the tickets are handled and try to understand why. That way we might discover some flows or processes that you could consider putting in place in your own organization.

Survey Results – Satisfaction goes down with complexity

In the 129 companies surveyed (mostly in the US, and some in Europe, too):

35% had more than 1,000 employees – enterprises

30% had between 50 and 1,000 employees – the SMBs (Small Medium Businesses)

35% had less than 50 employees – startups

Most companies were in the tech and software industry. Their job is mainly to build software, so you could assume that these companies are probably doing a better job at this than companies from other industries.

The exact question asked of these people was: How satisfied are you with the way tickets are handled in your organization?

We tried to avoid any bias as much as possible. Let’s have a look at the overall satisfaction rate.

So a lot more detractors (rating under 7) than promoters (rating over 8). Let’s now deep dive.

Does it depend on the tool?

One of the questions we asked was what tools they used to manage their software tickets. Tools range from Jira, GitHub, Trello, Built In-house, Bugzilla, Asana, Phabricator, Pivotal Tracker, Redmine, Rational and Other.

We didn’t find any real correlation from the tools. Sure, the company samples were not broad enough to make a definite conclusion on this, but the averages were kind of the same. One exception is Pivotal Tracker, for which the way tickets were handled seems more appreciated. We’ll come back to this a bit later.

What about the size of the company?

We got some definite correlation there. Here are the NPS scores per company size:

That seems pretty straightforward. The bigger the company, the more projects there are, the more complex the processes are – and the more tickets, too.

What about the role?

We considered only three roles in the survey results. Here are the NPS scores per role:

What can we infer from this?

The managers are, in general, the ones most likely to manage and assign priorities, and thus tickets. Therefore they have to handle a larger number of tickets per day, compared to other roles.

Most engineering directors and VPs seldom put their hands on the ticketing tools. They only do so if they are warned about a particularly impactful bug.

Software engineers mostly deal with the tickets that are assigned to them. Some do ticket estimation and priority evaluation meetings and therefore go through more tickets than the ones just assigned to them. In general, the more senior you are, the more tickets you are exposed to.

——

Overall, the survey data indicates that the more tickets you have to handle, the more processes you are exposed to, the lower your satisfaction. That seems pretty intuitive. Maybe we can learn more through the interviews.

Interview insights – Added value to the process seems to be the issue

We did about 40 interviews from March to July 2018, with both people who said they were satisfied and not satisfied with the way tickets were handled in the organization. Our goal was to analyze the comments – especially the ones unique to each of the two groups – to identify interesting patterns.

Most of the comments on the tools themselves were not unique to satisfied or unsatisfied interviewees. For instance, most tools were said to be slow; it takes too much time to load pages, especially when you look at plenty of tickets. Another instance is communication, described as a cumbersome experience. The expectations for communication have changed since Slack has become a standard. It seems we all want a unified interface for communication, to discuss inside the tickets without having to load the ticket page. Jira is actually putting some effort into this with their new tool – Stride.

The comments that really caught our eyes…well, ears…were about workflows. The people that invested the most in customizing the tools to adapt to their workflow tend to be significantly more satisfied. Sure, they complained that it required a lot of effort, but once done, satisfaction rate would go about 2 points higher.

Make the tool work for you

We were at first astonished that Pivotal Tracker showed a better satisfaction rate for the way tickets were handled. But, when you stop to think about it, Pivotal may be the most opinionated tool. It clearly doesn’t suit all teams’ processes and workflow. In some instances of constraints, you can only use Kanban and you are required to estimate features with story points.

But if you’re ok with this, Pivotal will automatically compute your story point velocity for each of your sprints for your whole team. It will then decide which tickets will be part of the next sprint, based on the average velocity and the story points of the tickets. Pivotal brings you value by removing you from the decision process of what should or should not be in the sprint.

Disclaimer: We don’t use Pivotal Tracker in Anaxi and will probably not, since we don’t have a workflow adapted to it.

Our point here is that it is worth the time to customize the tool you use (Jira and Trello are clearly not opinionated, and you start with a clean slate with them). Adding constraints in the tool can help you enforce your workflow by automating tasks or limiting your possible actions. Constraints can be your friends!

Different roles mean different needs

Another pattern that is worth mentioning is the role-specific feedback we got.

Upper management, for instance, complained about the lack of visibility they had on the multiple projects they oversaw. It’s hard for them even to know if their teams are late or not on their next milestones, although it seems a basic question. If you have the same kind of issues, you should take a look at what we do at Anaxi.

A lot of developers complained about how tickets are assigned and prioritized by some managers who are not as knowledgeable about the product and the code as they are. Unfortunately, that’s an entirely different discussion! And I wouldn’t dare go into it.

How to make it better?

Handling tickets is cumbersome per se, so you need to customize your ticketing tool so it helps you in this process. The example of Pivotal shows how it makes the decision concerning what will be in the next sprint for you. This removes humans from the decision-making loop and simplifies the ticketing process.

Here is another example worth mentioning from among the companies for which every role was very satisfied with the way tickets were handled – Matters Inovia, a French startup. They use Redmine, clearly not an opinionated tool that automatizes anything! However, Redmine (as with lots of other ones) lets you build custom tools on top of it. Matters Inovia builds plugins on Google Calendar, so their developers can log the time they spend on their tickets. Calendar events are linked to tickets, and the amount of time spent is logged in Redmine automatically. At first, it seems like a very cumbersome constraint to log time. But actually it has become a habit, and their tools even notify you if you haven’t logged your time.

What’s interesting about that? Well, now they know how much time has been spent for every ticket. They build some machine-learning algorithm to estimate all new tickets, and therefore know how much time a project will take. When their developers estimate how much time a ticket should take (yes, they also do this so their developers become better at estimating), Redmine will tell the developers when their estimations seem more than 40% off their AI-powered estimation. Matters Inovia builds a lot of apps for other companies; that’s why having good estimations have a huge impact on their business and are strategically important. But if you ask any of their employees if they’re happy with the way tickets are handled at their company, you bet they are! Other ideas that we heard about and that may be worth considering:

Tickets cannot be created without being assigned, to spur action

You cannot have more than one assignee on a ticket, to avoid confusion

You can link tickets together – whatever projects they are on – so bottlenecks are more easily identified, and communication goes through more easily

If a bug of utmost priority is left unattended for N days, the assignee should receive some kind of notification or visual cues.

—

We hope this analysis will help you rethink your workflow and how to customize your tools. Remember, constraints can be your friends. If you are interested in improving your processes and workflow, we’re building a platform Anaxi that will integrate with all your tools and offer customizable reports to show you how your team is performing and how your projects are doing. you can’t improve what you don’t measure, right? Follow us!