Far too often the backlog is housed in a tool somewhere, often in purely text form, with no way of knowing at a glance the status of each item. This makes it difficult to manage in many ways, and generally hard to work with. I have found that taking the time to visualise your backlog will not only increase the quality of the output, but make it a lot easier and less time consuming to work with. This is an example from my current project of how that works.
Your backlog as a process:
Most people don’t take the time to see their backlog as an actual flow, but it is. Items usually have a sort of process that they flow through to arrive in a state where they can actually be worked on, and being aware of what that flow is can help a lot in creating stability.
This ”refinement process” is, in my opinion, one of the easiest wins in most teams. Our team went from having 1-2 day Sprint Planning meetings, to usually getting through them in a just a few hours, with a much higher quality of output.
The backlog on its side:
The first step in creating a refinement process, is to visualise it. In the simplest sense this can be accomplished by simply turning the backlog on its side and seeing each section of the backlog as a column in your flow.
The tool we use for this is KanbanFlow. The images you see here are simplified slightly for the sake of clarity, they only show one teams flow, when in reality we have multiple teams working in this flow.
Below you see the complete flow, and we examine each section in turn.
Here sit the totally unrefined items. Some of them may be too big to work on, most are too unclear, and all are only ”lightly prioritised”. We like to visualise the different flows in to the backlog separately. This makes it easier to balance priorities against one another when planning upcoming work.
- Full of large, unclear stories.
- Many of these may never reach the top, we try to clean this out every so often and remove things we are certain will never be top priority.
- Most of these items come from our Product Owners / Customers.
- Holds much of our technical debt.
- These generally tend to be concise, but somewhat large.
- These items primarily come from the teams working on the product.
- Bug list
- A list of bugs that were not quite important enough to be a priority right away.
- We try to keep this list as small as possible, but some things do need to wait until they are worth the investment to fix.
- These items usually come from users who find them in production.
This is where the bulk of planning and discussions happen. There is a column where action from the customer is needed, and one for when action is required on our side. Most of what takes place here comes down to regular discussions which bring up question that need to be answered before development can start. Very often, large stories are split into smaller items here, and some of the lesser priority things go back to the bottom of the backlog, and the prioritised items continue forward.
Items do not leave this area without a clear priority.
This consists of items that are ”Ready” to be worked on, and items on which work has begun. Many teams choose to have a formal definition of ready, our team keeps it fairly simple: ”Everyone in the team agrees these items can be worked on now”.
Items which are pulled into the Sprint column are being worked on by the team. At this point, these items are made into smaller and more specific tasks, and are visualised using the physical tool for the team. This is important, because it is the main points where details are obfuscated. Our customer does not need to know exactly what is being done on an item, what matters to them is that the feature or functionality is started, and when it has been completed. This setup allows them the appropriate amount of detail.
At the moment we have a slightly heavy deployment process, which involves handovers to the customers organisation and wait times. Visualising this helps our customers to understand when things are ”done”, but they still don’t have them due to internal processes. This has aided in our customer driving many initiatives to simplify and streamline this process. While we still feel it could be improved further, it is definitely an easier process today than it was before we started visualising this part of the process.
Being aware of how items flow in your backlog from the initial request to the actual delivery can help significantly in many ways:
- Clear status of items in process for both you and your customer.
- A shared understanding by all involved what is in the pipeline.
- Easier planning session because everyone has more insight when items arrive.
- Higher quality to items arriving at the ”ready for development” stage.
But be careful not to present unneeded information as it only serves to make the needed information harder to find.
And most importantly, the tools used in the process are much less important than the process itself. Having the discussions regularly and openly, creating the feedback loop as quickly as possible, are the keys to success not the tools being used to present the information.
This process can be tricky at first, but as with all things, the more often you do it the better you will get at it!