I have developed a task management tool. And some task lists can be very large. (I have myself more than 300 tasks to do).

I would like to do some task reviews from time to time as the tasks pile up to be able to sort them by priority.

I imagine presenting tasks 2 by 2 to the user and ask him what task is more important than the other. Repeat until all the tasks are sorted.

Note that:

  • The algorithm need to be "halt resistant": the user can abort the review when he wants to and the result of precedent sortings would not be lost.
  • The tasks already have a initial rank already set by the user by hand that represent the priority.

My questions are

  1. What is the best algorithm that reduce the number of comparison needed to sort all tasks ?
  2. Do you have a better strategy to propose (or way of presenting the tasks and questions) in order to speed up these reviews ?


Thank you very much for all this feedback !

To answer some questions:

  • Yes, each tasks have responsibles and each responsible can order all (thous their) tasks.
  • We already have tags, but a tasks review is there to determine priorities among them. I agree that priorities can also be set by features and at the task level.
  • I do not want to have a tree of tasks classified by features and lose the flat list. I prefer a flat backlog with tagged tasks. It is sometimes very useful to prioritize a task belonging to a not so important feature placed later in the queue.
  • I realize that I maybe have first focused on this problem on the software level (asking for an algorithm) but my question is maybe belonging more to a project management group. I wonder for example how the agile review meetings are held.


The more I think about it and what is my goal is (asking this question of this algorithm), is that I want to make it fun to do the tasks review.

The ultimate goal is keep tasks ordered by priority. But it is danting to review tasks. I'd like to have a sexy interface where tasks are presented, and the user could play while doing his review. The sexy/playing part is up to me, but I have a hard time finding a way to logically (algorithmically) present tasks and then order them, giving that the user can stop this process at anytime.

Say I present 2 random tasks, and that the user says that B is more important than A and stop there. Then what ? Does that mean I simply update the rank to b.rank = a.rank - 1 (lower the more important it is). And why randomly by the way ? Is there a logically thing to do there ? You see, I don't know how to proceed.


I received a lot of input and I will greatly profit from all of them, so a big thank to all of you.

  • 4
    Unfortunately, comparison based sorts are not guaranteed to be consistent (e.g. imagine three tasks A, B, C with A > B, B > C, C > A). Where priority is roughly equal, the user's ordering will be effectively random. In practice, breaking ties in priorities by considering due dates or dependencies is likely to result in a better UX
    – amon
    Commented Apr 5, 2020 at 22:45
  • 1
    @MickaelFM - this is a harsh forum. I'd guess the downvotes are because this is more about project management and user interfaces than the theoretical side of software engineering theory. FWIW, I think the human side of software engineering is important too! Commented Apr 6, 2020 at 11:45
  • Do the tasks come from a range of different stakeholders? Could you ask each of them to sort their tasks? Commented Apr 6, 2020 at 11:50
  • 1
    As a suggestion from someone using lists like these - please add something like a tag or a sublist. What I hate is having to manually order a bunch of items. I tend to mentally split them in groups and then put the groups in terms of priority inside the flat list. So, it gets really annoying when you hit, say, 50 items. In reality, I may not even care about the order of some sub-group, while another might have a very strict ordering required. I'd love to have multiple lists available, not a single one.
    – VLAZ
    Commented Apr 6, 2020 at 13:08
  • 1
    Big offender are wishlists - sometimes I only want to look an item later I don't actually desire it. So, I wishlist it as a way to bookmark, since that's the only option available to me. So, I may need three types of wishlists - things I need to buy, things I might buy with a deal or something, and things I (most likely) wouldn't buy. There are, of course, many other sublist variations, like gift ideas or "for <something>". Tasks are the same - you could have top priority what has to be done, good ideas - what might be done, and backlog - stuff to be evaluated later.
    – VLAZ
    Commented Apr 6, 2020 at 13:08

7 Answers 7


Bucket Sort

But I'm getting ahead of myself.

Consider the use cases of listing and sorting tasks like this.

  • A dev completed a task and needs to know what to work on next
  • A Project Manager needs to estimate a delivery date
  • A customer/stakeholder needs to be assured that their requests are Very Important to you

All three of those really only care about the top portion of the list. You also need to consider that the list is likely to change over time as things get added naturally, the one customer to request a feature left (making their requests moot), or new features subsume older requests. By the time you get to items 170-175, the work around them will have changed significantly, so there's not much point in quibbling over their exact order. You can start doing that when they end up in the top 20-30.

Here's how to avoid the problems outlined above. Start with a bucket sort. Define several different categories for relative importance; colors work well here. Avoid naming them with emotionally charged words like "critical" or "important", because everyone wants their requests to be "important", and it will skew the ratings. Instead, use either broad descriptions or canonical items as break points. A good top category might be "data loss, corruption, theft, or misrepresentation". If you use canonical items as decision points, you can either use real ones or generalized ones like "the new icons are one pixel too narrow, so pad them in CSS to compensate".

Then, use your new standards to group the tickets into rough clusters of relative importance. In sorting terms, it's similar to using quick sort with seven or so predefined pivots. You end up doing at most three comparisons, but after the first few your team will likely have someone suggest a category initially and discuss from there.

After you have a basic categorization, you should have zero items in your top category and a small number in your second category. If you have more than zero items in your top category, then stop this sort process immediately and work on those items.

Next, you can subsort the first non-empty group of items by any preferred method. Repeat with the next group as necessary until you can satisfy all of the three bullet points at the top of this answer. Any farther and you're likely wasting your time.

  • That's a really good idea to make buckets, it's like sprints in Agility, and sort tasks inside them, with the ability to move tasks between buckets, (thus changing priority) if needed. I will implement that. It does not answer directly my need to ease the reviewing of all tasks, but it will greatly improve the ordering / prioritization, and that do anwer my original question in some ways. Thank you !
    – MickaelFM
    Commented Apr 7, 2020 at 14:35
  • 1
    @MickaelFM It's a bit different from a sprint. A sprint is the stuff you think you'll get done in two weeks (or your preferred sprint duration). If your first 20 items are all front end, and the team thinks they'll get seven done, then you still have the back end team start from item 21, even though they're lower priority. That's because the goal of a sprint is to know what will be done in two weeks, not necessarily to have the highest priority stuff done. Not all devs have the same skill sets or project context, so sometimes you skip stuff. Commented Apr 7, 2020 at 16:03

For 300 tasks you'd need to ask thousands of questions. No one is going to do that, and even if they did the results wouldn't be very useful.

For situations like this I'd suggest you stick with the requesters simply assigning an importance factor to each of their requests. If you have competing users, the software can also have a hidden user-importance factor that weights each requester's own importance.

But if users can already assign weights to their requests, why not simply let them change those weights whenever they want. Give them tools that they can use to meet their needs, and there won't be a need for scheduled task reviews.

And don't let your system (or the users) confuse "importance" and "urgency". For instance buying a birthday gift for your spouse might be very important, but if their birthday isn't for another 6 months it isn't urgent. Similarly "come here and look what this guy across the street is doing" is very urgent (he'll stop doing it soon and you'll miss it), but it really isn't important.


That's exactly what already exists. The ranks I was talking about are given by the user, reordering tasks by drag and drop. But imagine that you have 300 of them. You never actually look at them all. We need to help users to do a review of all tasks.

If the requesters can already maintain their own lists, I don't see what the real problem is that you are trying to solve.

If the requester doesn't remember or care about something that they asked for, it really doesn't matter does it? No one can legitimately complain that you aren't working on something that they felt should be in queue position 300.


  • Any request that hasn't had any activity in the last 6 months (or some other more appropriate period) should generate a mail message reminding the requester that they can increase its priority or retire the request. (The message would be considered "activity" and reset the clock.)
  • Create a special lowest-priority for which these messages never get sent. This could be used for items that were created simply to record minor bugs, annoyances, suggested improvements, etc., which aren't serious enough to spend effort on now, but which should be considered the next time that specific software has major work done to it.
  • Thank you for all these ideas and feedback, it helps a lot. I'm trying to clarify my thoughs and will get back to your reply.
    – MickaelFM
    Commented Apr 7, 2020 at 10:03
  • and to reply about the problem that I'm trying to solve: it is not the technical prioritization itself that I'm trying to solve, but the overwhelming work of reviewing a lot of tasks.
    – MickaelFM
    Commented Apr 7, 2020 at 10:46
  • I like the idea of asking the user for each tasks the level of importance (ROI) 1, 2 or 3, and the level of urgency 1, 2 or 3, and then sort the tasks based on that. Still thinking about it.
    – MickaelFM
    Commented Apr 7, 2020 at 12:35

1 What is the best algorithm that reduce the number of comparison needed to sort all tasks ?

Strictly speaking, merge sort is hard to beat.

2 Do you have a better strategy to propose (or way of presenting the tasks and questions) in order to speed up these reviews ?

Yes, stop stacking up unfinished tasks! 300 is ridiculous. Break down your problem into features that can be completed. Task out one feature. Do one feature. Don’t carve up the whole elephant before eating any of it.

Over planning sets you up to fail because it strangles your ability to learn as you work on your project. Your design should get smarter as you go.

  • Working at features level is good for prioritizing features. Putting tasks inside features is also good for classifying tasks. But losing the ability to sort one tasks over another just because they do not belong in the same feature is unproductive. Sometimes a simple task belonging to a not so important feature will help other users. So I prefer to keep tasks in a flat list and features as tags attached to tasks and be able to see only tasks labelled a particular tag.
    – MickaelFM
    Commented Apr 7, 2020 at 10:11
  • It is not over planning to note every idea you have in a list. I know I will not do all the tasks. But I like to know that I didn't lose a good idea. And I do need to review these ideas from time to time.
    – MickaelFM
    Commented Apr 7, 2020 at 10:11
  • 2
    @MickaelFM: Your question is inherently based on the complexity of keeping order in a giant flat list - which is a direct consequence of you specifically choosing to enforce said flat list. You've created your own uphill battle. Sometimes, the solution is to go around the mountain instead of how to improve on climbing it, and this seems to be one of those cases.
    – Flater
    Commented Apr 7, 2020 at 12:06
  • @Flater Yeah, I agree. I'm still thinking about all this.
    – MickaelFM
    Commented Apr 7, 2020 at 12:20

The algorithm should reduce the number of comparisons, but also the access time: when the user discovers a task, it takes time for him to read it and recover the memory he has about that task. So when the user has selected the most important of two tasks, you may keep the winning task for the next round. A benefit of this method is that the most important tasks will be well sorted first, while the less important will stay longer in a random order: that’s great because the less important tasks will get implemented later, and things will have changed by then.

Another way to reduce the access time would be to show 5 tasks at a time instead of 2, and ask to sort these 5 tasks.

And since you say you want to make it fun, maybe it should sometimes be 5, sometimes 2, sometimes sorting them, sometimes picking the most important, sometimes the least important. This can make the process less repetitive.

  • That the first real algorithm presented here, thank you Alexis !
    – MickaelFM
    Commented May 16, 2020 at 8:43

In practice you wouldn’t sort 300 tasks just by priority.

Tasks are related or unrelated. It is usually more efficient to handle related than unrelated tasks. So you would want to perform related tasks together. Also to have some subject handled completely instead of random bits and pieces.

This is much better handled manually.

  • Thanks you for your suggestion !
    – MickaelFM
    Commented May 17, 2020 at 4:07

Instead of presenting 2 tasks to the user to prioritize, you can provide an option to the user where the user can view the list of all tasks and has an option to reorder tasks based on the priority through drag and drop.

  • 1
    That's exactly what already exists. The ranks I was talking about are given by the user, reordering tasks by drag and drop. But imagine that you have 300 of them. You never actually look at them all. We need to help users to do a review of all tasks.
    – MickaelFM
    Commented Apr 6, 2020 at 11:06
  • 2
    @MickaelFM, in my experience, people look at two places in such a task list: where new tasks are added and the first "page" (or what they consider to be a page worth of tasks). Everything outside those ranges is not important enough for consideration until there is an explicit trigger to locate a particular task and put it higher on the priority list. Commented Apr 6, 2020 at 12:29
  • It’s not feasible for 300 items.
    – gnasher729
    Commented May 18, 2020 at 7:13

The problem is not the algorithm but the UI.

Split the data into screenfuls. Let the user sort each screen by dragging items.

Then combine the sets using a modified merge sort: Display half a screenful of two sorted groups, then let the user pick which comes first in the merged list - usually the first of one group, but users can pick items lower down because users are not consistent.

Best to split the data into 2^k groups initially.

On the other hand, I doubt the value of having 300 items sorted, because after the first 20 have been done priorities will have changed.

Not the answer you're looking for? Browse other questions tagged or ask your own question.