If you are using todo.space you might have come across a new feature that shows you some handy suggestions to improve your project health. One of the metrics we use to determine that is the number of boards where there are just too many tasks. Why? Here's a short story.

Creating tasks on autopilot

I was working in a company that used Jira as a primary task management and project tracking tool. One day I found an issue in our product that I wanted to fix, and so I needed to create a Jira ticket to track the progress of that task. All of our tickets were living under one epic or another, because how else could you manage a healthy project with healthy thousands of tickets? I am, by no means, a Jira expert, so let's follow the steps I needed to take to log my one-line ticket:

  • Open the page and navigate to the issue search
  • Open advanced search, because there is no quick filter for epics
  • Type in query project = "XXX" and type = Epic AND resolution = Unresolved because I'm a software developer and my heart glows when I have a chance to flex my query-writing muscles
  • Pray for epic I need to exist

I was a bit out of luck and there was no perfectly appropriate epic to put my task into. I cringed. Since there was no epic, I needed to create one, think about the good name and description for it and then put my task there. So I scanned the list again, and aha! — I found one that was remotely connected to the subject matter. The page took a while to load because of 546 tickets that were already there. There was no description. It was created three years earlier by a person who no longer worked in the company. I happily dumped my ticket there and went back to coding. Why is this bad for us though?

Mere mortal's nuisances

First, epics served no project management function to us. There was no definite goal attached to them, no time pressure to complete them. They were just buckets for categorizing tasks. And so they grew steadily throughout the project lifespan. This means that almost no epic was getting complete. In fact, the number of completed epics was about 5% of the total amount.

Second. Every time I think of epics they evoke pictures of big projects in my head, like launching a satellite, building a nuclear power plant, or at least ditching SOAP for JSON in a big enterprise product. The word "epic" bears too heavy meaning for what I need. I don't need an epic that will imply work of epic proportions, I just need a simple todo list for these types of things. And so I feel disincentivized to create new, more appropriate epics for my humble tasks. Jira seems to cater more to a power user, however — the one that would find exciting functionality of bulk ticket editing in an epic of 546 tasks. And so these epics stay in this state of perpetual 85% epicness as tasks flow into them to get completed immediately, and the stated goal of the epic expressed in its title seems to be as far away as it was three years prior.

Mission-critical tasks

Let's examine this from a company standpoint too. Every single company has a reason to exist, reflected in its mission. How good the company delivers on its mission determines if it stays in business or goes out. And rarely, if ever, there are fewer tasks deemed necessary to fulfil the mission than the company's capacity to execute them. In other words, some of the tasks will not get done, and it is in a company's best interests to prioritize its backlog in a way that will get the company closer to its goal without going bankrupt.

How do you prioritize a task in the epic "Make my company great", and how do you do that with other hundreds of tasks there already? You either don't prioritize it at all and risk working less productively as a result of picking less important tasks; or your understanding of priorities lies outside your project management software; or both. That's why we decompose the core mission into a set of projects and sub-projects with their requirements and time constraints. When putting a properly formulated task in one of those backlogs there is a much more defined goal towards which the work should be done. With a much more defined goal, it is therefore much easier to see — if the task at hand is truly necessary.

In our case, perhaps unsurprisingly, it was quite hard for me to see what cool goals were accomplished. All I saw was a wall of almost-done-but-not-quite epics, so I had to ask people to find out if something was already complete, or not. Luckily for us, we had a firm understanding of our priorities, it was just more in a form of verbal agreements. This allowed me to dump my task into the "least inappropriate" epic and still manage to get important work done first. What was a minor inconvenience for me as a developer could have been something much worse for the company as a whole, had we had a less robust company culture.

A better tool for the job

We noticed this pattern in todo.space too. Some of the boards in our projects grew quite large over time, so we set out to fix that. Now the health indicator can show us if some of the boards become too bloated. And it is very easy to create new boards in todo.space too. In fact, this is exactly what we did when we found out that the project we track todo.space development in had a couple of such boards as well — we created a bunch of new specific boards and relocated misplaced tasks there. The process took less than a minute.

Have you tried todo.space lately? Let us know what you think in our Slack workspace.
If not — try it for free!