So why do we have a backlog? Usually because there are not enough hours in the day to accomplish all the tasks we know need to get done. Usually our sprints are only two weeks long and there is only so much you and the team can accomplish in that short time. We end up just throwing the rest into some sort of repository for the next go around. Now we have this repository and it is full of the things we have said that we could not get done, but now we must manage it. How do you tame the backlog monster?
The first thing would be to determine what goes on the backlog. All too often I see backlogs with years’ worth of items on them and we know they are never going to get done. My advice is to only keep items on the backlog that you know can be scheduled and worked on within the next 3-6 months. Everything else can go into a “Parking Lot” and reviewed periodically to see if the task can be pulled into the backlog. If a backlog gets too big it will be difficult to manage.
You may ask what type of items go into a backlog? In the diagram below from the BABOK v3 show the most common items on a backlog:
Each task in the backlog needs to be described with minimal detail. We just need enough information to trigger our minds of why it is in the backlog, but remember a lack of detail can result in a loss of information over time. We do not need full requirements on anything that is in backlog status. I suggest a heading and a very short description of the task (25 words or less). As you prioritize item higher in the backlog list they can have more detailed added to them.
|
Category
|
Heading
|
Detail
|
Priority
|
Story Points
|
|
Documentation
|
Order Import Documentation
|
We need technical documentation created for the order import process on widget software.
|
3
|
13
|
Determine how you are going to track the item. Why would we track an item on the backlog? If you break your backlog down with categories then they can be grouped together when a new sprint starts. It also nice to have the high-level story points or an estimation on the task. These will get refined as they get moved into the sprint. Then you will prioritize the items. This should always be done with the project team. This is not something that one individual is responsible for; It is the voice of the team that will guide the prioritization of the task in the backlog.
The next question is how often do we track the backlog? The simple answer all the time. Backlogs are living documents that feed the next sprint. The word “backlog” can be interpreted negatively in conversation. I will have a conversation with all my new product owners on a project where I explain to them that the “backlog” is not the “graveyard”. When I say we will add that to the backlog I am not brushing you aside but adding you to group of work that needs to be prioritized and worked into one of the next sprints. Once people understand the process of the backlog and how it is ever changing they tend to not get upset when they are told that their item is now in the backlog because they know it will be worked on in the next few sprints.
When we ask ourselves, “What are we going to work on next?” At this point we have a backlog that has been groomed and managed. It is ready to be used. In the agile environment we will prioritize our backlogs with all the stakeholders every two weeks. It is a standing meeting and everyone has input and a say on the prioritization of the backlog. All the information needed to feed the next sprint is there. If anything is missing we have all the right people in the room to get any details needed or more accurate estimates. Often, I can plan out 2 or 3 sprints in advanced with a well-maintained backlog.
Lastly, how do we know when an item needs to be removed from the backlog? The longer an item is on the backlog the less likely it will be done. This could be because of how long it will take to do, lack of resources or the cost of doing the task. You can set up a simple rule that say, if it has been on the backlog for 90 days then it gets moved to the parking lot. Another reason something can be removed from the backlog is because it is no longer needed. Sometimes we have tasks that we want to be done but then something comes down that changes the whole flow of project and the original task is no longer required. Finally, if the work would cause a defect then it should be removed from the backlog.
In conclusion, I hope this information helps you maintain a backlog that works for you and your company. Remember it is a living document that needs to be groomed and put on a maintenance schedule so it does not turn into an unbearable monster that is out of control.
