If there are many tasks in the backlog and the product owner keeps adding them, some of the tasks become outdated and in practice they are never implemented by the team. Why don't we borrow some techniques that are used in thread scheduling to prevent thread starvation like:

  • aging – task's priority could be automatically increased over time
  • guaranteed time slice – it could be guaranteed that in the next 10 sprints a task is taken into the sprint for at least 1 sprint.

It could prevent the tasks from being outdated like operating system prevents threads from being starved.

  • 10
    "the product owner keeps adding [tasks]" This is your underlying problem. Commented Jan 14 at 8:07
  • 6
    @PhilipKendall: no, it's not, Quite the opposite.
    – Doc Brown
    Commented Jan 14 at 10:12
  • 23
    And voters, remember, downvotes are for bad questions, not for bad ideas.
    – Doc Brown
    Commented Jan 14 at 10:43
  • 8
    You are assuming that every task should be done. That's absolutely not the case. However if by "taken into the sprint" as in "we will spend a reasonable effort to evaluate if the task is obsolete or not and if not if it makes sense to be done or not" then you might have something that could work, although you still will not have any guarantee, you'll just end up with a slightly cleaner backlog with periodically evaluated tasks... but this still takes some time from actual development work so it's not free
    – Bakuriu
    Commented Jan 15 at 7:48
  • 8
    There's a fundamental theorem in queuing theory: If you put things into a queue faster than they come out, the length of the queue approaches infinity, and so does the average amount of time that things have to wait in the queue. Many engineers who don't know anything about queuing theory and don't think queuing theory applies to their problem find themselves trying to disprove this without realizing it. Not that I'm a queuing theorist either, but I think it's very funny that such an obvious thing is missed so often. Commented Jan 15 at 16:15

6 Answers 6


There is no issue with collecting new feature ideas for a product in the product backlog, even if those ideas will not be implemented within the next five years. Not every idea for a feature is worth the effort to be implemented now, still it might be worth to collect the ideas for keeping up a strategic development plan and evaluate older ideas from time to time.

However, the situation that some of the feature ideas are demanded by a lot of users or stakeholders regularly, maybe in different variations, can be more easily detected by bookkeeping those ideas in the backlog. We can add a remark to the item, telling who has already asked for the feature, when, and - not to forget - for what purpose(!). This can be an indicator for giving this backlog item a higher priority and pull it into one of the next sprints.

When some of the tasks really "become outdated", as you wrote, in the sense that they became obsolete, one can consider to delete them (and not to give them an even higher priority, obviously). Maybe the code base has evolved up to a point where the task makes no sense any more, maybe the feature is covered by some other features which are already implemented, maybe the feature idea itself has become obsolete because the use case does has lost importance for the users or can be solved differently by some 3rd party software. If the product owners detect such items, they should either remove, archive, or rewrite them.

Let me disclose that I am not talking about theory. What I wrote above is part of my daily work. One of the product backlogs I maintain is more than twenty years old (we actually never called it "product backlog", the approach of keeping such log items is quite independent from Scrum and applies to almost any long-term product development, regardless of the methodology). This backlog contains more than 200 open feature ideas which might be implemented at some day in the future. Still we would never priorize them "by age", that would definitely make no sense.

  • Although I agree with this, there are people who will have an "issue with collecting new feature ideas for a product in the product backlog". See the #NoBacklogs movement. There are plenty of arguments made by proponents, but none that I consider to be strong or convincing.
    – Thomas Owens
    Commented Jan 16 at 13:03
  • 1
    @ThomasOwens: thanks for the keyword, didn't know this, I looked it up. Those people surely have a point. If one maintains a backlog for a long-living product the way I scetched it, one surely has to care for who gets to see it and that it is not misinterpreted. Though the backlog contains several customers ideas, I usually don't show it to customers. Instead , I have a high level document with the mentioned strategic development plan at hand, focussing on the planned things for the next 6 to 12 months. This is also what we use in the team.
    – Doc Brown
    Commented Jan 16 at 14:34
  • 1
    Yeah. They have some interesting ideas. And having a very large backlog is definitely wasteful. And maybe this is my background in regulated industries, but we need to maintain a known issues list of reported bugs, including those that are so much of an edge case we won't fix them. That's a backlog. I do think you need to clean it up and be able to show the right things to the right stakeholders, but the #NoBacklogs movement made more sense before the widespread use of electronic tooling with searching and filtering capabilities.
    – Thomas Owens
    Commented Jan 16 at 14:38

Why should a task become ever more important just because it's old? The point of agile methods is to decide what to do based on current info, not on outdated info. If you do it properly, then a task that keeps getting not pulled cannot be the most important task.

  • 3
    This. If anything it should be considered if you need to keep the task at all -> if it actually had any priority, you would feel the pressure from the stakeholders to go about implementing. Furthermore, this is a sign of bad backlog and sprint - you should actually aim for your sprint load to match the actual team capacity / velocity (these days usually inferred indirectly through comparing with previous sprint deliveries). Whoever is managing the backlog should actually take care not to have the "aging" items in the backlog.
    – Jas
    Commented Jan 14 at 10:07
  • 2
    @Steve: If the originator is annoyed at the task not getting completed, and they're not footing the bill as a stakeholder, there's an easy option - they foot the bill for another developer to take time on their preferred feature request. If enough stakeholders are and product owners are happy with the current result, then it may be that the task was achieved through a different ticket because the implementation of how that idea should be done may have changed during intermediate builds, and better ways were devised. That is what "The point of agile methods is based on current info." means. Commented Jan 15 at 5:33
  • 2
    @Steve why would the PO be editing the code? Or why would the developers be the ones gathering the requirements? A simple typo fix would still cost at least 30 minutes of work, if not more. If it's high priority for the end-users - sure, that time can be spent there. Or it can be spent on something the user thinks is more important. It's down to priorities.
    – VLAZ
    Commented Jan 15 at 11:33
  • 3
    @Steve Users should still be the final arbiters of what they want. Not time. I can't imagine a user being delighted being told "we implemented these 10 minor things that you reported ages ago. Rather than the business critical feature you told us about a couple of week ago". Users' priorities can change, I doubt they all wait with bated breath for every single minor thing. In fact, I know for a fact they don't. They are usually happier receiving business critical functionality (something that saves them hours a day), instead of minor and easily overlooked cosmetic improvements.
    – VLAZ
    Commented Jan 15 at 14:28
  • 3
    @Steve if a user does feel something relatively small is a priority, then by all means, that's what they should communicate. More than once I've seen clients been asked "But what about X which was reported months ago, are you still interested" and they'd say "no" for a vast variety of reasons. Some times it just loses priority, or just loses relevance (e.g., functionality that is going to be changed/removed), or it was reported by a previous employee and the current one has different opinion. Etc.
    – VLAZ
    Commented Jan 15 at 14:29

Who says that you can't? Just because the practices aren't prescribed by Scrum doesn't mean that the Product Manager can't implement them. In fact, the Scrum Guide even says that you can add to it:

Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

There's also the argument that having too much work in the Product Backlog hampers the transparency and understanding of it, so unnecessary work should be removed, and there are indeed many ways or criteria to remove something from the Product Backlog.

Today, electronic tooling to manage the Product Backlog means that you don't need to necessarily discard or "throw out" anything - you can use filtering to keep the team and stakeholders focused on the most important work while still keeping track of older, less relevant ideas and having a way to find them (and perhaps any decisions made about them) if you need to in the future.


I actually use almost the opposite approach. I maintain a tiered priority backlog: A has 2 items, B has 4 items, C has 16 items and D has 64 items, and then the idea graveyard.

Adding an item to the list defaults to adding it to D and the oldest-since-last-touched item goes into the idea graveyard. Items can bubble up in priority by swapping with an item from the next highest section, again by default it is the oldest-since-last-touched that gets deprioritized.

The main idea here (besides clear priorities) is that new ideas are shiny and exciting, but bubbling them up into higher priority requires those tough questions about priority and timing. After a while the shininess wears off and those that people really want to keep on the list are "touched" to keep them there. (See also Bets, not Backlogs).

  • What happens when items get done? Do the empty spots get auto-filled from the next level, or only with an active decision by which item to promote? Commented Jan 16 at 1:05
  • Today I use an active decision every 2 weeks (before sprint planning). Commented Jan 22 at 16:44

Empiricism and value. Scrum is an empirical process where we take new knowledge and make decisions based on all that we have learned and use that to find the most valuable items for the team to pull into every sprint. Just because it has a long lead time does not increase the value, in fact, often as time goes on it becomes obsolete. We never want to guarantee an item's delivery date because we don't know the order of future valuable items. New items may become more important for the team to work on


Is an old task automatically outdated? In the feature-enhancement queue for some software I'm working on is a request to change the workflow for a task to require one click rather than four. It's been in the queue for more than twenty years now, and is still as relevant as the day it was entered.

Is an old task automatically worth working on? The task in question isn't performed very often, and it's questionable if the time lost from the inefficient workflow has yet exceeded the time needed to implement the change.

Thread scheduling is based around the assumption that every queued task is worth working on. That's not true for software development.

  • it's not an answers, you only add more questions and make it less clear
    – banan3'14
    Commented Jan 16 at 19:41

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