Avoiding backlog chaos

Empower your product team by linking your strategy and backlog

If you can relate to feeling like your backlog is living a separate life from the overarching goals of the business, it probably means that the people managing the backlog are struggling to control its size. Saying “no” is hard, but bloated backlogs are even harder to manage.

The challenge comes in connecting a company strategy directly to backlog-level tasks, which are small, detailed, and implementable.

What you should do instead is build the link from the company strategy to the backlog step by step. The linking steps are as follows:

• Product vision
• Product strategy
• Product goals
• Roadmap
• Backlog

The frequency of backlog changes

Aside from startups, a company’s strategy doesn’t normally change, not drastically anyway. But this doesn’t stop the backlog from bloating with new content, usually multiple times a week, due to the likes of gaps in the market, bugs, and support/change requests.

The chain of work

In project management, a chain of work is the sequence of tasks that need to be completed. Each task relies on the completion of others, forming a chain.

Parts of the chain of work are positioned at the two dimensions as in the picture below.

Picture 1: Chain of work

If we look at a situation where the links are missing, it looks like this:

A bloated backlog can also be combined with the roadmap. This leads to bloated, confusing, and hard-to-use products, and naturally, leadership struggles to steer development, resulting in low productivity and high volumes of unplanned work, which looks something like this:

Disconnected work leads to silos where sales become one camp and development another, leaving product managers in firefighting mode and leadership unhappy with the results.

How to exit the chaos

The people who should be building the links (product managers or leaders) are so busy putting out fires that carving out time to work on a solid vision, product strategy, or product goals becomes increasingly difficult. Many of our customers have realized this and asked for help facilitating the process or coaching the people responsible for linking work.

Are there shortcuts? In my experience, product goals can help. Even without a concrete vision or product strategy, by adding product goals, leadership, product managers, and developers can prune their bloated to-do lists and align work toward a common goal. This is a great place to start, and some organizations even stop here because it resolves the issue.

Product goals also help in another way by reducing intervals. Product goals force the cadence to be much shorter as they’re usually set in two to three-month intervals.

A complete chain of work (like in the first example) keeps the whole team focused. It increases the level of trust that leadership has for development work to proceed in the right direction. It also allows teams to perform smaller, more focused experiments to determine the direction. Without a chain of work, those experiments will have to be more broad and high-level, yielding less concrete results.

More successful products and higher business Agility

If a true chain of work is built like in the example, it can lead to even more effective outcomes and increase self-organization.

What is the outcome of a well-executed chain of work? I think it can lead to increased Agility on the whole business level, transforming the chain of work like this:

We are still anchored in the strategy and product vision, but a well-executed chain of work can result in fewer changes on the backlog level, with more Agility on the product strategy and goal level.

There is less unplanned work that messes up the backlog, more gets implemented from the actual roadmap, and there is higher throughput in the product goals. This allows product leaders to react faster to new business opportunities and is most effective when combined with other solid DevOps practices.

It has to be noted that I have stopped this model at the backlog level. It could potentially be extended to cover operations work as well. Of course, a true DevOps team would have ops-related work combined into the new development and bug fixing in their backlog. Where you need to extend your version of this chain of work depends on your team’s level of DevOps maturity.

How to begin

First, identify and establish the necessity of the work. You need to get everyone on board because it requires time and effort. Second, discuss how the product leaders can find the time to do the work. What schedule is realistic (taking into consideration other urgent tasks)? Third, help product leaders decide the suitable format to document work. This is the stage where external help can be most useful.

Once you have set up a practice, decide on regular reviews to keep it up to date. Most companies work the strategy cycle on an annual basis, but this will not do for the middle parts of the chain as shown in the pictures above; it needs to be quarterly.