Our company is small which makes it easy to implement this kind of methodology, so in the last few projects, we’ve been perfecting the processes maintaining the backlog and estimating time. This is because I believe that nailing down time estimates and keeping the list / backlog updated are the two critical pieces for the framework itself to do well.

Here’s some of the things we keep for each entry in the queue / backlog:

- ID – A unique identifier for each of the entries, for quick reference. It’s good to have something to look for apart from the description.
- Description – A description of the unique feature on the list. In the case of software development this might be something like “Add a form to allow people to comment video entries” on a video website.
- Priority order – The order in which this should be built if we were to organize it by business value * team availability. This is also how we sort the list.
- Estimate – An estimate of how long in terms of man-days (one man working one day) something would take. Example: 4 man days means that 1 person would take 4 optimal days implementing this feature.
- Test spec – How to test that the feature was correctly implemented. When you wrap up a feature and mark it as “done”, the steps outlined in this test spec should be used to validate the solution.
- Discussion – A discussion/note area where details about the particular feature go. This is obviously optional, but we find that it is a great place for clarifications.

There’s a lot more I could mention about how we do prioritization or how to select a combination of “features” or backlog items to work on a sprint, but it is probably material for more in-depth posts about queues.

PS: Love the idea of this blog, I hope I can contribute more and more often with comments. Hope this one helped.