Have you worked on a project with multiple customers representing multiple customer roles? For example, there may be a product manager role, a customer support role, a system operator/administrator role, and so on. I’ve seen this happen several times. The stories might also be conceptually organized into new features and technical debt (including refactoring and bug fixes). Ideally, your group of customers is “speaking with one voice” but in actuality there are usually competing interests. Some stories are planned and some are not. Most teams maintain some type of story backlog for these unplanned stories. The problem is that, in the worst case, technical debt or administrative features might never be worked because the product manager is completely focused on new feature development.
XPlanner has been criticized by some for not having an explicit mechanism for representing story backlogs. The reason this mechanism has never been added is that it generally works very well to create a pseudo-iteration to store the unplanned stories. As stories are planned they are then moved to a real iteration. One advantage of this approach is the extra flexibility compared to a built-in backlog mechanism that only supports only a single backlog.
If the backlog is viewed as a prioritized story queue, then some of the stories may become starved for attention (similar to starvation in prioritized task queue systems). One technique for preventing starvation is to set priorities of stories as a function of how long they’ve been in the backlog. The longer the stories have languished in the backlog, the higher the priority.
I don’t like this approach. The priorities have meaning to the team that set them and modifying the priorities automatically will risk losing that meaning. There’s also the problem of comparing priorities across different roles and types of stories. It can be difficult to compare the priority of a technical debt story to a new feature story, for example.
Another approach is to create multiple backlogs. In XPlanner, this means creating a pseudo-iteration for each customer role or story category (depending on how you want to group the stories). Given an overall effort budget for an iteration, the customers decide on how to partition that budget to the various roles. For example, new feature development might get 75% of the budget, technical debt reduction is allocated 15%, and system administration features get 10%. The stories are then planned from each backlog, in priority order according to the specific backlog, until the budget has been allocated to stories.
This technique reduces the risk of starvation for categories of stories without requiring dynamic story priority modification or attempting to compare priorities between the story categories.