How to make task list less depressing?

There are a myriad of solutions that seek to address this problem - Waterfall, Kanban, Agile etc.

However - I think they address the symptom of the problem and not the root cause. Which is mostly Bad Management, poor leadership and toxic work culture.

A List of Despair is not caused by what is on it.

Consider a big project, it's going to be on the board for a while. Maybe you break it down agile style into smaller sub-jobs.

If you have a Boss who is constantly nitpicking, on your case about something or demanding to know why things have or have not been done - then the list becomes a source of Dread.

Everyone gets apprehensive about the Meetings because they know that giving the 'wrong' answer (e.g. the one Management doesn't want to hear) - will result in an ass-chewing or lecture or any N number of negative outcomes.

Now - consider a Boss who is supportive, helps with the Workload, inspires leadership and works with you to get through tricky roadblocks, has your back with upper-management etc.

Run the same list (hypothetically) as with the previous hypothetical boss - and I bet you that it is not a List of Despair or a source of dread.

TL;DR - The problem was never the list

In agile scrum methodology which this seems vaguely based on, you specify a length of time called a sprint (generally 1 or 2 weeks) which your team divides work into. There are several reasons for this, but in your case in particular, it's to prevent people from feeling overwhelmed by the never ending to do list. If all you can see are the 10 items the team is supposed to work on this sprint, then it's a lot easier to feel like you're making tangible progress. On the other hand, if what you see is a list of 500 items, finishing one feels completely uninspiring.

There are 3 places you can have todo items:

1. In the current sprint. These are supposed to be worked on and finished by the end of the sprint.
2. In a future sprint. If you know a task needs to be completed by the end of the month, but your team is full for the current sprint, you can stick it into the next one.
3. In the "backlog". This is where tickets go when it's unsure when the team can get to them. Midway through each sprint, you hold a backlog meeting where the team looks at items that they have in the backlog and decide if they should go into the upcoming sprint.

By doing this, you ensure the team doesn't have a never ending todo list. Instead, they have discrete todo lists separated by weeks, and they can see actual improvement from day to day.

Edit: You specified no arbitrary deadlines, which this advice goes against. However, I would argue no arbitrary deadlines is not actually advisable. Sure, you absolutely don't want people crunching every day to hit some randomly assigned due date, but without deadlines you lose all sense of time progression and it feels like you're doing the same thing every day. If on the other hand they get to the end of the sprint and they feel like they were able to finish everything they were supposed to, it's a good feeling. If the team always struggles to get the tickets done by the deadline, you can investigate the root cause (are tickets too vague? too large? is the team constantly distracted by "urgent tickets" from other sources?). Without a deadline, you lose the opportunity to learn what could be improved on.

I think one of the main things with task lists is not to let them grow too long relative to capacity.

There's nothing that annoys the rest of the staff of the business more, than endless waits for various kinds of service, or arbitrary and unpredictable prioritisation of things already enrolled onto a seemingly endless list.

Excessively long lists also exert an overhead for those working from them in terms of constantly parsing and re-parsing the details - grooming the list - and will make progress on the list seem Sisyphean.

Also, once there are a certain number of pending tasks, patterns will often emerge that allow them to be organised into a single bigger job or project that share some commonality in terms of concepts or type of work involved to solve them - such as a suite of screens or reports that cover one general area. So it should be possible sometimes to consolidate a set of tasks into one larger item.

Welcome to 2025 - you want to look into agile processes. These are bog-standard in IT (planned software development but also ongoing unplanned incident management), but also perfectly applicable (if maybe not as well-known) to other industries. Indeed, many of the concepts were originated in automobile production, decades back.

This is a pretty big field, but it also does not need to be overwhelming, and the core concepts are pretty simple: you have your tasks (or stories, or incidents, or whatever you call them). You place them on "boards" and thus make them visible to all, including management and stakeholders. Then you work on them, updating them whenever you process. Finally, when you encounter impediments, you also update the tasks and start yelling for help.

You usually have two heaps of tasks: one is the "backlog" - an arbitrarily large amount of tasks which are not currently being worked (or even looked) at. You basically know that they are there, but ignore them for all intents and purposes.

The other heap is often called the "board", which can either be a physical whiteboard (or just a wall in your office, if you have that) with a piece of paper for each task; or a digital solution which does the same; for example, Jira (but there are a great many, and you can roll your own in Excel or whatever you have).

Tasks on the board will go through a process, and will be in one of several states at any time:

• Open - nobody is working on it
• In process - somebody is working on it; you can add the name of the person to the task.
• Done - it's finished but stays on the board.

Once in a while, when the "Done" heap is large enough or when a predetermined amount of days or weeks has passed, you have a meeting with management or stakeholders, and present all your "Done" tasks.

This is it in a nutshell. There are a great many details you can fine-tune, from requirements on a task before it can go onto the board ("Definition of Readiness"); requirements before it can go into the "Done" column ("Definition of Done"); additional states (e.g. "Impeded" or "Waiting for more info"). You can have different ways of how to pick tasks from the backlog. You can have someone responsible only for the backlog itself. You can have someone responsible for moderating the process itself, helping the team. And so on and forth.

The agile processes differ on how and when you meet, and what you do in those meetings. I won't reproduce all that here, go read up on them yourself. But all of them target exactly the problems you are describing (for example going through all open tasks daily - that's a big anti-pattern).

Reading material:

• The Agile Manifesto - this is for software development but a very to-the-point introduction for "Agile" in general, really. This gives more of a "feel" to what it's all about, without prescribing a concrete process or way of working.
• Scrum is one of the well-known fleshed-out processes. It is planned and forward-looking; it divides the time in a number of weeks, and each of this iterations ("Sprints") is planned and executed, with the expectation that there are little changes from the plan.
• Kanban is the most common starting point for a more flow-oriented process; it does not pre-plan sprints, but lets tasks come in and go out more fluently. It's great for teams that have few planable tasks and many interruptions/incidents.

A couple of options here.

1. Work on descoping list items that really aren't that important or have been on the list for so long that by implication aren't important enough to actually complete. Items that have been backlogged for months can get dusty. Several items may well have been solved or rendered obsolete by a subsequent piece of work since they were created.

2. Consolidate related items on the list into fewer, more "meaty" work items - by putting things together into a larger item of work, you have some hope of creating a piece of work that involves a more holistic solution than just little bits of sticking plaster.

Don't use (just) a list

I get it, lists are easy to set up, read and use. Well known and well understood and for any of these reasons a widely accepted default.

But - as you're experiencing - they're also not always that well suited. There's a reason why the entire tech industry does not have their tasks in lists (alone), but are using Boards with work items.

source: "trust me bro"

The other answers present different faces of the situation, and I mostly agree with them.

However, nobody mentioned specifically that the tool itself might be a source of problems itself. I did not use Microsoft SharePoint > Lists, but a glance using a search engine tells me that it is not optimum for the job at hand. Since the tasks can be presented in a list, maybe Lists is good. But on the other hand:

... they're small projects and action items, not many recurring tasks ...

which it makes me think that a task manager (also known informally as a bug tracker) would provide significantly more benefits compared with a fancy list. This kind of tool can easily answer some of the problems presented ("is X done yet", set priorities, create dependencies between tasks, schedule tasks, and even reporting charts and dashboards). Of course, additionally to the tool, they should have some minimal project management done there - which seems to be mostly (completely?) missing.

I will not give examples of task managers, since there are plenty of them, both commercial and free.

What can I suggest to management to make the staff task list less depressing?

If you can use a better tool, is even better.

But since a lot of the problems are related to the lack of project management, you can try to train the team into project management activities. To be more specific, in tasks management, setting priorities, making dependencies between tasks, taking responsibility, setting deadlines, scheduling the activities etc.

For each of the topics I mentioned (and mentioned by others), please feel free to come back and ask other questions - if you do not find easily an answer somewhere else (maybe even on this site).