In which order perform tasks from big backlog

Question

I have a big backlog of tasks gathered during last years. And new tasks are added occasionally. All tasks have the same priority and tasks never expire over time.

I was thinking of the reasonable way to have them done

1. Do the newest task first. I see the flaw of this approach, that the oldest tasks may never get chance to be done

2. Do the oldest task first. The flaw of this approach, is that newest tasks lose their actuality.

3. Random shuffle order.

4. Combined approach. Do 1 newest, 1 oldest, and 1 random task.

That's just approaches came to my mind. But I'm looking forward to know if there are any well-known approaches that are proven to be efficient

UPD: some key requirements were not clear

• all tasks are independent, and finishing one has no impact on any others
• all tasks have the same difficulties
• most recent tasks have a bit higher importance while they didn't lose the context, however it should not lead to the flaws of the 1(LIFO) model

Answer 1

One of the most important things to do with a backlog is groom it. You should go through the backlog and prioritize the tasks.

It can seem overwhelming when the backlog grows faster then it gets cleared but understand the backlog isn't simply a to-do list. It's a documented record of how critical the proposed work is. Simply being in the backlog is not a promise that it will ever be resolved. Sometimes the backlogs job is to remind us that we've seen an issue before and decided it's not critical.

Focus on that. It shouldn't matter how old an issue is. Just how much we care about it.

Answer 2

This question seems to address tasks as if it was for the classical elevator optimization problem:

1. LIFO has the risk of “starving”: some tasks will wait forever for resources and will never get done. Unless people do what they usually do impatiently in front of an elevator that is not coming: press and press again this button. Or in project management, they’ll escalate to the hierarchy again and again until there is a significant pressure to change the approach.
2. FIFO has the risk of doing all the things (if there are enough resources), but maybe not in the best order. Important tasks get delayed, which might have a big negative impact (money lost, security flaw still not patched which leads the CEO to explain why the personal data leaked for 2 years despite everybody knew it was an issue).
3. Seems strange, but it will not be worse in average than LIFO or FIFO. In fact, recent work about elevator optimizing used genetic algorithms, i.e. use some randomness.
4. It is not clear if it is out of despair, or a new way to combine the drawbacks of all the others ;-)

This works for elevators because the question is about waiting time of tasks that have similar outcomes.

This is not applicable for the real world, because it ignored value and risks, which are a key to any more complex endeavor:

• if tasks are for an autonomous robot, ignoring the risk of falling in the stairs might be fatal for this device.
• if tasks are for developing a new product, ignoring the value might give a good chance to the competition. And ignoring to address uncertainty early in the project may make this project a nightmare.

So the answer is “None of the above”.

A safer and more universal approach is:

• put all the tasks in a priority queue sorted by decreasing priority. You can call it backlog.
• always process the highest priority first.
• define the most appropriate way to assess the priority. It’s usually a combination of value, risk and urgency.
• from time to time reassess the priorities to be sure to work on current facts and not according to an obsolete plan.

Finally, if it was for your own personal life, get a copy of the fascinating “Getting things done”, which give some nice practical tools to implement the general algorithm in your daily life, without getting lost in theory.

Answer 3

You say "all tasks have the same priority". In that case, do the first task on the list, then the second task on the list, and so on.

In reality, since you have a long backlog, nothing on it can have very high priority, where "high priority" means it is important to perform the task now, not later. So that's not what you go buy.

Assign each task a value, based on what benefits will be realised by performing the task, and a cost, which means how much time it will take to perform the task. Take into account that you get a huge benefit from just removing a task from the backlog, so say fixing a typo in an error message has tiny benefit for fixing the typo, but huge benefit by making the backlog shrink by one item.

Next group tasks together that are in the same area of code and that can be QA'd together. When that is done, you pick a group of tasks that have the best value / cost ratio and do them all.

Note that when a backlog is old, lots of the things in it tend to be outdated. Someone may ask for bugfixes in an area that doesn't even exist anymore. So close things that are not relevant anymore.