7 rules to manage your backlog

Using a Backlog for your product is one of the best ways to sort requests and to manage your development effectively and efficiently. If you do it right, you’ll always keep a clear focus on customer value. With a traditional project management background, you probably remember a similar element called Work Breakdown Structure (WBS). But be careful, a WBS is fundamentally different from a Backlog. The latter is a living element in your project that adapts to new insights and, most importantly, focuses on customer value. A WBS, on the other hand, is a static, one-time summary of the components required to complete your project and, frankly, has no value or focus on your customer.

If you want to take advantage of a Backlog and if you want to lead your team based on the most valuable features inside your Backlog you should follow the seven rules below. Otherwise, your Backlog will only be a waist of time. I am sure there are other topics to be considered when managing a Backlog. Especially, if you include tool specifics guidelines. But no matter which tool you use these seven rules are the must follow topics in order to take advantage from your Backlog.

Sort items on a timeline
You should use at least three different time horizons to group your elements. Namely, a short-term, medium-term, and long-term horizon. In agile terminology, this is typically referred to as iteration, release, and roadmap horizons. The granularity and level of detail is defined by the time horizon into which the item falls. The items closest to the timeline are the ones you should focus on the most. Items that are farther away should be discussed and worked on regularly, but not as intensely as the near-term items. Each product has its own rhythm and you need to figure out if long-term items need to be discussed monthly, quarterly, or just annually.
Separate new items
To keep control of any new items coming in (e.g., from team members, customer feedback, suppliers, management, business analysts, etc.), separate them from the rest of the Backlog. Review this area regularly and only then move them to the Backlog.
Hide won’t do items
Once you have decided not to do an item, it should be moved out of the way so that you can focus on the remaining items. On the other hand, you might change your decision in the future and, in that case, you still need to have the items in your Backlog so that you can reactivate them when needed.
Group items by feature
Especially for teams with a lot of experience in traditional project management, don’t fall into the trap of grouping your elements by components, business units or other internal scales. Always take a customer view and group your Backlog by features. Customers are only interested in features and they usually don’t care about how you are organized internally or how the product is structured. Another big advantage of features is that they can be defined much more independently. This makes it much easier to split and size them for the next iteration or release.
Review the Backlog on a fixed schedule – and stick to it
Every Backlog needs good maintenance. If you don’t regularly review, sort, detail, remove, or discuss the elements of the Backlog, it won’t help you and your team. Instead, your Backlog will run wild. A fixed time slot to review your Backlog is one of the most important slots in your calendar and you should never skip it. As the Backlog grows, sometimes it cannot be managed by one person alone. In this case, it is even more important that everyone checks the Backlog regularly so that each section of your Backlog is up to date and has the same visibility when you plan your next items to work on.
Refine only short-term items
Everyone agrees that the items for the next iteration need to be detailed enough for the team to understand and work on. But what about the other items? It is advisable to also detail the items for the iteration after next. But you should not spend too much time on all the other points. You should have just enough detail to do a relative weighting so that you can use it to estimate the remaining effort. If your team has trouble identifying when an item is detailed enough, it might help to define a clear structure for detailed items. A detailed item could have elements such as Story sentences (Who needs What and Why), Definition of Done, or any other structure you need in your project.
Define a Backlog owner
Even if the Backlog is too large to be managed by just one person, you should designate one person as the fully responsible owner. If your company has specialized technical departments such as mechanical engineering, software development, and electrical engineering, try not to assign responsibility to someone from these departments. They are usually unaware of their bias and tend to group elements into technical silos. It is better to assign a Product Owner or Product Manager as the Backlog owner. The most favorable setup, in my opinion, is a Product Owner responsible for the Backlog and a Business Analyst to support him or her. This setup has two main advantages. First, it gives the Product Owner a partner to work alongside on the Backlog, and second, the Business Analyst provides an additional focus on business value. A more traditional setup might be the combination of Product Manager and salesperson or System Architect. Be careful with traditional roles like Systems Architects. They don’t always have a customer view of the product and sometimes tend to gold plate.

I wish you success in your projects and I am sure that you will deliver valuable products if you consider these seven rules.

Do you have any more questions?

Introducing the Lean Team Organization

Introducing the Lean Team Organization Why a New Organizational Structure? Over the last 15+ years I have worked in most of the existing organizational structures currently known.

Re-thinking how organizations work

Re-thinking how organizations work Think about the organizational structure you work in and evaluate the following questions: Do you work in a line, matrix or