Whether you are doing an agile project or not, I firmly believe ALL projects should use a backlog. I actually am going to mention two types of backlogs we use: product backlog and a BA backlog.

When you are in a software development project of any kind, you likely have software developers who need something not-so-fancy to tell them what to work on. One thing that has worked well for ages and likely always will – a checklist of work items. Before I go on, I want to be clear that I’m not suggesting this is the sole source of information about requirements! This backlog is a list of work, but there should be requirements with RML™ models that help them understand how to implement the list. But, back to my point on backlogs….

Often we track requirements in one tool and defects in another. In our case, we are also tracking enhancement requests in the defect tool since the business identifies them while they are doing testing. The trick is that we need one complete list with all of this information in it – so that we can prioritize the entire list. Because simply put: Developers build requirements, developers build enhancement requests, and developers fix defects. And it may be the case that a new enhancement request is more important than fixing a defect. This is where a backlog is key – to merge all these lists into one list that determines the entire list of developer work items and the priorities drive their development work.

We also track all of our remaining Business Analyst work with a backlog. I have found that the business analysts are often pulled in so many directions – elicit requirements, review design, help with testing, prioritizing features, retest fixes, etc. And depending on the phase of the project the BA can really get pulled in too many directions and lose site of what is most important for the BA to be doing. A BA backlog that tracks the work remaining is a good way to manage this – working with the team to prioritize all of the work that remains.