Best algorithm to sort tasks by priorities by a human

Question

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 ?

EDIT 1

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.

EDIT 2

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.

EDIT 3

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

Answer 1

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.

Answer 2

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.

UPDATE:

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.

Perhaps:

• 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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.