"Project Backlog" is negative

A friend of mine recently pointed out that the term "Project Backlog" from scrum for the work still to be done in an Agile project has negative connitations. It sounds to non technical people like the project is behind, that there has been a build up of work and you're having to catch up. I think this is probably why Ken Schwaber chose that term, the project is only up to date when all work outstanding has been done, but I'm having a difficult time selling the idea to my customer and I think it is because of this negative connitation I hadn't previously thought about.

In the project I work on are in the enviable position to have spare development capacity and not enough customer capacity. Customers write stories for an iteration days, sometimes hours, before the iteration planning meeting and only have time to write one iterations worth of stories. The customers look at creating stories for the "backlog" as unncessesary because we're always crying out for more stories, why bother store them up. This is a big problem for us in development. We can't see what's coming up so design decisions often have to be reworked in the next iteration. Prioritising work to be done is missing becasue we just do the work when we get it. Design has to happen in the iteration where the work is done and we sometimes do work that wouldn't be necessary if we had a slightly longer term view of the upcoming work.

So I think it's time to rebrand the list of work still to do. Suggestions so far are "Work item list" or "Work Pool". I really llike the work pool name because it creates an image of something that has the same properties as I want from my list of "work to do". Diving into an empty pool is obviously dangerous. If a developer runs out of work they can dip into the work pool and many other useful management metophors. I'm sure you can think of others.

Let me know what you think and any other names you can think of.

Pete