25

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.

Thomas Owens
  • 85,641
  • 18
  • 207
  • 307
camilajenny
  • 365

6 Answers6

40

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.

Doc Brown
  • 218,378
33

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.

Kilian Foth
  • 110,899
8

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.

Thomas Owens
  • 85,641
  • 18
  • 207
  • 307
4

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

camilajenny
  • 365
Michael Deardeuff
  • 259
1

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

Rachel
  • 21
1

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.

Mark
  • 363