In Scrum methodology of Agile software development we define work backlog as “an evolving, prioritized queue of business and technical functionality that needs to be developed into a system.” In practice, the work backlog is a collection of stories and tasks organized by development priorities. It may be on:
Front Burner – those Stories and Tasks that I am actually working on right now; they are in the current iteration.
Back Burner – Stories and Tasks that I intend to work on soon. I have probably tentatively assigned them to the next iteration, and I allow myself to think about them.
Fridge – Stories and Tasks that I might do someday. They’re on the list, but I am not actively thinking about them right now.
The work backlog is a common concept, so rather than belabor it; here is a short list of its attributes:
It is developer focused, as it shows the stories and tasks that the developer is working on, or will be working on;
It is focused on the order of development, emphasizing the stories and tasks in the current iteration;
The primary metric that is used with the work backlog is velocity, which measures (using a variety of metrics) how many stories or tasks the team develops per iteration.