Mastering task trackers: DOs & DONTs
Task trackers are widely used in many companies. JetBrains’ Issue Tracking Tools Review shows that roughly 7 out of every 10 respondents have experience using issue trackers in their work processes.
I must confess I am one of the biggest fans of task trackers. I am obsessed with keeping all tickets in order and having a structured view of current and past workload. My husband and I even used a task tracker to manage our apartment’s reconstruction and decoration. It was a bit weird to create tickets like “order a sofa” or “calculate how many bathroom tiles we need”, but it worked pretty well for us and helped to keep track of all tasks.
At work, I used issue trackers much more heavily — I must have created thousands of tickets so far, using these tools on a daily basis for 9+ years. It’s an absolute must-have tool for me to manage my own work and the work of my team. I start every single working day by going through the tasks on the agile board.
So today, I would like to share my view on getting benefits from tasks and avoiding common traps. If you or your co-workers don’t use the full power of task trackers yet, you might find some hints on what you could improve.
I won’t speak about particular issue trackers’ functionality. If you are interested, you can search for special guides on it. There are quite a lot of them, for example, best practices for JIRA — the most popular issue tracker.
DOs
Let’s start with the things that tickets can help you with.
To-do list
A to-do list is the most direct way to use a task tracker. I usually work on several projects simultaneously, and from time to time, colleagues reach out to me with small requests or questions. For me, it’s almost impossible to keep all these tasks in my head and not lose anything. That’s why I prefer to write this down.
From experience, I know that a to-do list works well only if you have one source of truth for all your working tasks. That’s why I also use a task tracker for storing these small requests.
To be clear, I don’t create a ticket for every single question. For example, if a colleague asks me about our retention, I just provide the link to the dashboard. My rule of thumb is if getting an answer takes more than 10 minutes, then I create a ticket for it.
Knowledge base
One of the main functions of task trackers for me is a knowledge base. It’s an invaluable source of information for previous and current projects. I usually refer to the task tracker to find earlier analyses for the same topic or to understand the implementation nuances from the engineering tickets.
A knowledge base may be helpful for either small or large teams. Keeping it up-to-date requires a lot of resources and discipline, and task trackers can make it less painful for you. Task trackers allow you to add small batches of information collaboratively. And if your team actually uses a task tracker, then the knowledge base is automatically up-to-date and shows the current state of projects.
Of course, there’s no way that such a treasury will appear magically without any effort. You need to work on it. Let’s talk about some tips:
- Make tickets as informative as possible.
From time to time, I have to revisit my previous tasks. It’s common in many teams to come back to the same ideas. I’ve noticed that in 3–6 months, I remember almost nothing about the task’s context, assumptions and logic behind decisions. And it’s normal. People tend to forget details. But these nuances and context may be valuable.
That’s why I prefer writing down all information in the ticket: what problem we are solving, what approaches we are using, why we’ve made some assumptions, what are limitations, what decisions we’ve chosen and what other methods can be tested in the future.
I have to spend some time on this, but it really pays off because I don’t need to communicate all these details again and again to colleagues, and I can reconstruct all the required information even after many months.
- Build a structure
It’s easier to navigate your knowledge base if you have some structure.
I often use “umbrella” or parent tickets to group all tasks related to one project. For example, suppose I’m going to implement a new monitoring & alerting system. First of all, I will try to split this vast and vague project into small manageable tasks. For example, define metrics we would like to monitor, investigate possible monitoring systems, build a prototype for one metric, test alerts, etc. Then I will create a main ticket for monitoring and subtasks for each item in my plan.
Also, I find it helpful to create a parent ticket for similar routine tasks, for example, updates for Monthly Business Review. Then you don’t need to spend time searching for the previous iterations.
- Link to previous & related work
In many cases, our work is related to tickets from other teams or to previous researches. For example, engineers implemented a feature, and now you’re analyzing an A/B test to estimate its impact. Or you’ve discovered that the retention rate started decreasing in previous research, and now you would like to understand why. In such cases, it’s worth linking to these related tickets to keep these connections. Surfing through such links, everyone can get all the needed details and understand all the context.
Reproducibility
Have you ever been in a situation where you need to reproduce your colleague’s work? For example, update numbers for a monthly presentation or investigate why you have different answers for the same question. I’m pretty sure that all analysts have faced such tasks at least once. When a colleague is next to you, it’s pretty straightforward: you can reach out to them and get all the needed details.
But have you ever been in such a situation when a colleague is inaccessible, for example, chilling on vacation in Africa? I’ve been. Facing such a situation, one starts appreciating the detailed tickets.
In my opinion, the calculation method should be stored right next to the results. You can just write it down in the comment if it’s something small, like a SQL query. For more complex scripts, I use a repository.
My favorite life hack to boost reproducibility is to have a special tasks directory in the repository. Then I create a subfolder for each ticket (for example, “ANALYTICS-42”) and store all code and files related to this project in it. In many cases, the task tracker will even link your commit to the ticket if you mention the ticket’s id in the commit message (for example, “ANALYTICS-42: conversions by platforms”). With such a structure, it will be effortless for anyone to find the exact code used for calculations and reuse it.
Transparency
As analysts, we work in collaboration with other teams, and our colleagues (especially project and product managers) may be interested in progress on our side. Tickets can answer all these questions (of course, if you update statuses accordingly), and PMs will start coming to you with more interesting questions than “have you already started working on ticket X?”
You can configure your own workflow and statuses if the default ones don’t fit you. For example, add statuses “in review”, or “blocked”.
Planning
Task trackers help in planning a lot. Most trackers have the functionality of agile boards, which allow you to plan your team’s work for the next period. Planning is a massive topic, so I won’t cover it in detail today.
Performance insights
You can even get some insights by analyzing the task tracker’s data. To do it more granularly, use labels to markup tickets.
For example, an issue tracker can help you to find answers to the following questions:
- What share of resources do you spend on routine tasks vs research ones?
- Do you split resources fairly between different projects?
- What tasks are constantly moving from one sprint to another?
- What type of tasks usually pops up during the sprint?
DONTs
Now let’s move on to the dark side — how one can misuse a task tracker.
Boldly using a number of tickets as people’s performance measurement
It may be tempting to use a number of closed tickets/story points to measure your team’s performance. I understand that it’s a very controversial topic, but I don’t believe in such an approach because:
- Tickets can be very different. Some of them you can do in 15 minutes, while others may take weeks. So the number of tickets is definitely not the best metric to evaluate analysts.
- Even if we start estimating tickets in story points or other units, we can make mistakes in estimations. Many times when I was working on a very straightforward task, I faced bizarre data peculiarities. As a result, I have been working on the task all week instead of the estimated half an hour. Also, your ticket can be just entirely blocked by another team. For example, the release has been delayed, and you can’t do an A/B test.
- Metric gambling. When you measure the quality of work by the number of closed tickets/story points, there’s an incentive to increase these numbers and create more tickets or give higher estimations. We can even recall Goodhart’s law: “when a measure becomes a target, it ceases to be a good measure”.
The impassable barrier between you and the requesters
Some time ago, I participated in a discussion (I would even call it a holy war) in one career chat about tickets and communications between design and product teams.
The topic starter mentioned that their team had spent more than a year asking the product team to create tickets for designers, and they still needed to succeed in it. The product team prefers to discuss tasks in meetings and forgets to generate tickets. Designers refuse to do anything without them. Eventually, designers do their job when the problem escalates to top management.
As I’ve learned from this discussion, such an approach is standard in some companies. It was a complete surprise for me.
I think we shouldn’t build these bureaucratic barriers like “we will start doing something only after you create a ticket”. A task tracker is just a tool. Use it to solve problems, not to create new ones.
I believe the main goal for analytical teams is to help the product team to make decisions. So our work is problem-solving, not just ticket closing.
From a more practical side, after discussing with the product team, I can create a much better-formulated ticket for myself than anyone else. I’ve already spent some time thinking about the problem, previous analyses and possible approaches, so I have even a broader context than a requester. That’s why I see no reason to require the requester to create a ticket.
Even if I get a new ticket that is a bit more complex than “dashboard is broken, please, fix”, I will reach out to the requester for more details:
- to try to understand the actual high-level problem and what decisions will be made in the end,
- to double-check that my assumptions and understanding are correct,
- to discuss the possible approaches to research,
- to align on a plan for the investigation.
The other pragmatic argument against working only on created tickets is the question of prioritization. If you are doing only tickets from PMs who are creating them quicker, are you sure that you are doing the most impactful and important things for your product?
The only channel for communication with the product team
The other trap I’ve found is limiting communications with other teams to just tickets.
The reasons why the team could choose such an approach:
- Analysts don’t have enough time or have too many threads in parallel, so they try to get tasks in the most structured and understandable way without spending too much time on communications.
- In some cases, managers (either product/project manager or team lead) can try to proxy all requests so the team can work more effectively and analysts don’t need to speak with not-so-easy requesters.
Working like this, analysts may be very effective and close 10+ tasks a week each, showing fantastic performance. But I would argue that it’s optimal for both the company and analysts. The back side of such an approach is a lack of people’s growth, motivation and creativity.
Usually, for junior analysts, we define tasks on a lower level: what metrics to calculate, what exact data to use and which nuances to take into account. For well-defined tasks, it’s indeed possible to communicate with product teams only in tickets because the definition of done is known and approaches are usually clear.
However, senior analysts are more than just those doing two times more tasks. They can face questions like “what market should we focus on” or “what is our next big opportunity”. To answer these questions, analysts need to work closely with the product team to get the best results, and it’s almost impossible to solve it without communication, brainstorming and constant feedback.
So limiting communications to mainly a task tracker may slow down the growth of an analyst. Also, I’ve seen many times when analysts were burning out and losing motivation while doing similar tasks every day without evolution.
Companies don’t benefit from this work style either because analysts are less likely to use new creative approaches and think out of the box. Creativity prospers when people see the high-level picture and share ideas with each other.
In my opinion, if analysts are only working on well-defined and 100% straightforward tasks, they will likely be replaced by ChatGPT in the near future. To grow professionally, an analyst needs to get out of their comfort zone, try to approach tasks with a higher degree of uncertainty… and talk to other people :)
Summary
To sum it up, I would like you to highlight these 3 points:
- Issue trackers can be your friends and help you to keep track of your tasks, effortlessly reproduce and validate your colleagues’ investigations, find needed information and even get insights on how to work more effectively.
- You can review documentation and learn more about all available functions to get 100% of the benefits from your issue tracker.
- Try to avoid making a task tracker a barrier to your collaboration with colleagues or limiting all the communications just to tickets.
