We all know by now the idea behind work item tracking. You all have heard before the word wit (either Task, Requirement, Bug, Issue, Risk, Story and etc.). Basically you can create those items and store them in a repository. This repository, the team foundation server work item tracking engine, is the backlog.
This is not “T-H-E definition”, however this is my definition for a backlog. A backlog is the location where we store all the “things” that we need to do during the ALM (Application Lifecycle Management) process. The “things” are translated into a work units, which can be Requirement, Task, Bug and etc. All the wits we create are stored, traced and evaluated within the given development process (SCRUM, XP, CMMI, Waterfall and etc.).
When you develop software or even hardware, there is one important rule in regarding to Backlog: “You should have one!!!”. There are many reasons why you should keep one, for example: Create a work plan from those wits or create an iteration sprint.
The backlog should always be maintained and updated according to the company needs. If you are practicing “Agile” process development, you should be able to add, remove and update items from the backlog. It is a challenging work, but it is worth it.
How to interact with it?
Basically, I like to think (and this is my preference) that everybody can suggest new work units. only the product manager can accept them and decide whether to add them to the sprint / iteration or to ignore them because they have no ROI or any other value to the company. The developers (dev team) can give estimations and derive new work tasks (activities) out of them and so on and so forth.
Team Foundation Server supply a very good infrastructure for creating and maintaining backlog. You can easily query those work units, update them, give estimations and derive new activities.