Multi-dimensional backlogs

How to become better at planning delivery of multiple features for your team

One of the easiest tricks that helped me to be better at delivering multiple features across all my teams was to move away from one-dimensional backlogs to multi-dimensional backlogs. And I don’t see this being used enough, so here we go.

*Disclaimer: I know that the ideal answer for this problem is to limit Work In Progress (WIP) and focus on one feature at a time. But the reality of working in enterprise product development is different - you may have a team of back- and front-end engineers, where back-end developers work ahead of the front-end and you want to prioritize their work separately; or you have a large team and small enough features to afford to work on multiple things at the same time; or you just work at a typical enterprise company, where you’re expected to work on a series of features at the same time satisfying multiple stakeholders. *

A typical backlog of a typical team usually looks like this - a stack-ranked list of stories where features intermingled. That’s how people are trained and that’s, frankly, how most of the Agile software works.

This serves the purpose of identifying the most valuable thing to work on, but at the same time, it intermingles multiple new features, bugs and tech debt, production support, etc.

But, the reality is more complicated and, well, it’s multi-dimensional. It is often close to impossible to identify the one most valuable thing when you work across a portfolio of stakeholders, features, initiatives, or users, with the added complexity of reducing technical debt, building future enablers, fixing bugs, and providing production support. And even if we focus on just new features - the most valuable thing for one of your stakeholders can be very well the least valuable to others.

Using a one-dimensional backlog in a multi-dimensional world leaves countless product managers to do the mental gymnastics to remember how they need to organize their work to deliver everything on time and to satisfy all of their stakeholders.

But what if there is an easy way to improve this process by introducing an additional dimension to your backlog and grouping it by features or work types? This approach worked fairly well for me and my teams over the years in different companies - I call it a “multi-dimensional backlog”.

Once we organize all features in their independent backlogs it gets much easier from a prioritization perspective. Stories within the same feature can be easily stack ranked, as they typically belong to the same user type or a stakeholder.

Our next step would be to understand how you suppose to spend your team’s time - this is what is called a capacity allocation. This can be driven by budget allocations, stakeholders negotiations, based on your team’s skills, or driven by external forces (e.g. market demand). Once you understand how you should divide your team’s capacity between multiple features, you can reliably plan for delivery.

You can also divvy up your capacity by departments or business units or by a group of features. In some companies, you can very easily tie those allocations by how much you get money from each of those departments.

Just remember to revisit this once in a while.

Once you figure out your capacity allocations between different features or feature types, planning an actual sprint becomes a breeze. On one hand, you have a list of prioritized feature backlogs and on the other side, you know exactly how to divide your team’s capacity - so it just becomes an exercise in picking up prioritized stories until you reach your feature capacity.

Voila.