Capacity Planning for a Balanced Backlog

Todd Olson was the VP of Products at Rally Software for a few years. I met Todd when he was the co-founder of 6th Sense Analytics here in the Raleigh-Durham area. Todd’s background is mostly as a software engineer, but after Rally acquired 6th Sense, he developed a wonderful sense for product evolution and management as well.

Not that long ago, Todd made a presentation at our local Agile Leadership Network group. It was entitled: Curing Feature-itis and it focused on the balancing act associated with planning a balanced agile portfolio.

In this article, I want to bring that discussion down to the Product Backlog level and discuss some of the aspects and techniques associated with keeping your backlogs healthily balanced.

Feature-Feature-Feature (Feature3) Syndrome

When I saw the topic of Todd’s talk, it immediately resonated with my own experience. I’ve often used a term to describe a common anti-pattern that I frequently see in many Product Backlogs. I call it—Feature-feature-feature Syndrome. It implies that all of the stories (or items) in the backlog are customer-facing features—100% of them. It also implies that the backlog is incredibly imbalanced.

What’s the cause?

Well, I’m glad you asked.

One cause is the consistent business pressure that every Product Owner is under, or at least every PO that I’ve ever met. One consistency in today’s software organizations seems to be that there is always more work than there is staff (capacity) to deliver it. And this pressure lands squarely on the lap of the Product Organization and the individual Product Owners.

I’m not saying this is good or bad—it simply is.

In the Scrum model, it falls to the Product Owner to “manage” the Product Backlog. Inherently they are empowered to and responsible for what goes onto it. But when the feature pressure is on, many succumb to it and only put stakeholder or customer facing features on the backlog.

Which isn’t necessarily bad for short-term bursts of activity, but for longer-term product viability, it can be an incredibly short-sited strategy.

So what is a “balanced” backlog?

Again, good question. And the consultant in me wants to answer with – “it depends”.

Seriously though, I think the answer can be somewhat clearer. A product backlog needs to contain all of the work required to create a product or project for a client. It certainly must contain software features or functional user stories – ones that are demonstrable, otherwise, what would be the point?

But there are things in products beyond the features themselves, for example, infrastructure development, architectural work, and testing activity supporting regulatory concerns. Here’s a more complete list of some of the components of a more balanced backlog:

• Development Infrastructure
• Testing Infrastructure
• Test Automation
• Testing Environments & Data support
• User Story – Research Spikes
• Architectural Look-ahead or Runway activity
• Design activity
• Bug fixes (from longer term defect backlogs)
• UX Design
• Time for Testing Traceability
• UAT at a system or product level

All things that I might want to capture on, and prioritize against features in a backlog. By reserving stories on your backlog, you reserve time for this important supporting work and make it transparent.

And these items, instead of coming from the stakeholders or customers, typically come from the team. In this view, the Product Owner is taking in feedback from all constituents and trying to do their best job of listening and ordering the backlog.

Who’s the boss?

Another thing to consider in your balancing act is that the customer isn’t always the boss of you. Yes in agile teams you need to drive towards delivery of value, but you also need to consider the needs of the team. Those needs often represent themselves in areas like: infrastructural, architectural, and refactoring investments; as well as in tooling for automation, testing, and code maintenance.

It’s these investments that often drive speed to market and quality improvement results. But they also reap good will and morale on the part of the team, as they feel you’re investing in their “health” as well as the product and that you’re listening to them.

A Story

In many of my Product Ownership classes I offer a dilemma to inspire thinking around balanced backlogs. I mention a hypothetical team that has a small group of database engineers on it—one is the lead and two are interns. The lead is about to go off on maternity leave for 2 months and she typically took on all of the complex back-end work for the team. While the interns have some knowledge and skill, consider what was a 2.5x productivity proposition across the three of them to be a .5 proposition with her on leave. So in essence a very significant drop in overall backend capacity.

As the Product Owner, would you alter the flow of work based on the capacity and skill-set change? Even if the business (customer, your boss, Senior Leadership) was pushing you for more functionality with significant backend implications?

Or, would you drive the work through the team independent of their capabilities simply because that was the right priority flow?

Personally, I would change the flow—balancing it towards the new capability of the team and wait for the lead engineer to return. Yes, I would make this transparent across the organization. And certainly I would also welcome some more experienced replacements, if we had them.

But I would focus on balance in the backlog even in the face of mounting “value pressure”. I think an important part of the job is maintaining your balance under pressure and adversity.

What’s the Mix?

There are essentially two ways to handle the capacity allocation mix in Product Backlogs. Either your leave it to the discretion of each Product Owner to “load” their backlogs appropriately or you define a specific target mix.

I always prefer the former approach IF the Product Owners feel empowered to own their backlogs and invest in the future of their products. But in nearly all of my experience, that isn’t the case, with the vast majority succumbing to the business pressure and creating Feature3 backlogs.

In order to combat this lack of empowered balance, many organizations negotiate a fixed ratio for their backlogs. A common one I see is 80:20; that is 80 percent features and 20 percent investment in other areas—sometimes including bug fixes. In several companies where I was the VP of Development and their internal Agile Coach, we leveraged this mix for our all of our backlogs.

What was interesting is that sometimes, we struggled to fill in the 20%, which always boggled my mind. It seemed that the teams were reluctant to write the stories to describe the 20% work, even though they continuously complained about the business’ background investments in our products.

Salesforce.com

Salesforce has an interesting twist or at least had it in the 2009-2011 timeframe*. In their case, they established a 20% “penalty” for products that didn’t minimally have 70% automation coverage, which often occurred with new product acquisitions.

What did that imply?

That they would invest in a normal mix for their products, let’s say 80:20. But if a product lacked sufficient automation coverage, they would invest an additional 20% of the backlog to bring the automation up to speed with their norms. And what’s even more interesting is that this was driven top down by management and not by the teams.

I particularly like this story because it amplifies the agile maturity of the Salesforce leadership team. They clearly understood that an investment in automation infrastructure was a longer-term investment in their products.

SAFe Recommendations

Moving on to another example. The Scaled Agile Framework (SAFe) strongly recommends a balanced approach in handling team capacity as well. But unfortunately SAFe doesn’t make any strong recommendations as to effective ratio’s or balance propositions. They simply leave it up to the organization to make that decision on a PSI by PSI basis.

While I understand that position, there are other areas within SAFe where they are quite prescriptive. I wish this were one of them. Here’s the reference for capacity allocation in SAFe.

Wrapping Up

I hope this article has at least influenced your thinking around capacity management and balance within your Product Backlogs. If you’re a Product Owner reading it, then I want you to walk away knowing that this is a significant part of your job—a job that your teams are depending on you to do well.

My main point is that you avoid Feature3 Syndrome. The other point is that it will take dogged determination, a longer-term view, and courage for you to maintain a healthy balance—particularly under pressure. While that may be a great challenge, your team will respect you for it and your products will be more successful if you achieve that balance.

In the end, it’s your choice.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

*Salesforce mentioned this at several conference presentations in that timeframe. One noteworthy example was at the Agile 2010 conference. I believe Steve Greene was the co-presenter.