Budget Your Backlog

We are all familiar with the concepts of budgets, right? Spend less money than you make, eat fewer calories than you burn, etc. Why is it so difficult to actually do? It sounds so easy, but man, that cupcake is good. Or I really want that car now, so let me spend more money than I make and go into debt.

Managing your backlog is a similar concept. You have an infinite list of things you want to do, paired with a finite list of people who do the work. The natural contention between those 2 things; prioritization. You are forced to reconcile the value of one thing over the next. You can't, however, determine value (accurately) without understanding the cost at some level.

Most of the time, a good backlog acknowledges the work a team needs to do so that a prioritization exercise can take place. Invisible queues are our enemy. I like to teach teams that there are really only four categories of backlog items (you can subcategorize however you wish or even rename the items).

  • Roadmap
  • Minor Enhancements
  • Defects
  • Engineering/Maintenance

Roadmap backlog items are visible bits of work you want to communicate to your customers and outline a plan for your product. It is also okay if those things have dates associated with the timing of releases.

Minor enhancements are items that are quick wins for your customers that they (or you) don't know they want yet. It’s a hallway conversation where you hear a customer say, "Man, I really wish the product did this." You take it to the team and find that it is a small cost, so you put it in to delight your customers. Minor enhancements can also be feedback loops that you are building into your budget.

Defects, well, are defects. We want the team to strive for zero known defects as part of being "done", but the reality is that you will never have zero-defect software. It is an asymptotic goal. Strive for it, but also face reality that the customer will inevitably find bugs that we did not and we need to react quickly to resolve them. Let's capture that spend as part of our budget.

The last category, and a little more nebulous, is the Engineering and Maintenance category. Every line of code probably costs your system money to maintain. You can't write a new feature or product and simply walk away. It takes time to ensure the system is running optimally and that we build in time for the team to take care of the system periodically. This means upgrading that 3rd party tool, refactoring the system to use the new framework, etc While the Product Owner owns the prioritization of the backlog, they should not do this in a vacuum. The development team should periodically bring these kinds of backlog items to negotiate the budget.

If you measure your backlog in Story Points, then that is your currency for your Product Owner. You can quickly measure the amount of work we completed last quarter or last year and build a budget based on that knowledge this year (and of course, take into account team changes, etc). This fosters a sustainable and constant pace for your teams by using metrics to help guide the future (yesterday's weather is the best indicator of today's weather). The most important part of this is that the Product Owner and the Team are involved and collaborating, effectively negotiating the backlog with those budgets in mind.

If you spend too much on groceries one week, you have to take it from somewhere. The same goes for this approach to planning your backlog. The times we need the team to work overtime can be an intentional/deliberate conversation with them involved, forcing our Product Team to indicate the value of such an exercise. If you do this all the time, then something else is wrong. Teach your Product Owner that they can go to the well twice a year (or something similar).

Once you actually look at where your team is spending its time, you can start understanding what is going well (or what is not going well) and ensure we are accounting for all the types of work beyond new features. This will help you manage your budget much better by telling each "Story Point" where to go, and every Story Point has a name.





Related Articles

Story Mapping to Prioritize

As we continue on our series through the end of the year (the one that focuses on prioritization techniques for our Product Teams), we land on Story Mapping in this post. I normally wouldn't think of Story Mapping as a prioritization technique, but in certain situations, I think it's perfect...

Read More

Like it or not, it's always about time and money...

My wife and I love to travel. Every year, we spend time contemplating where we would like to go next. Sometimes we spend a bit of time day-dreaming of what the place might look like and what airlines fly there etc...Then...back to reality. We keep these places in a list...

Read More

Eisenhower Decision Matrix (The 4D's)

Dwight Eisenhower was one of the greatest military minds and responsible for countless decisions during one of our world's most dire times (WWII). When I was in leadership training at FedEx (many years ago), I was exposed to the 4D's of prioritizing my tasks as a leader (Delegate, Delay, Discard...

Read More

Organizational ADD

We all have most likely heard the term; Attention Deficit Disorder (or formally known as Attention Deficit / Hyperactivity Disorder). ADD or ADHD are the short phrases we use to identify those who lack the ability to pay attention for any length of time and are very active / motor...

Read More

Priority Poker or Planning Poker

Prioritization significantly influences the development of a solid roadmap for Agile/Scrum organizations. It is a challenging and time-consuming task unless you have an easy and effective technique that helps to find out the right order of work. Luckily, there are various techniques for feature prioritization that we have been exploring...

Read More

The Sprint's Locked?

When I am teaching / coaching teams on the use of Scrum, many of them ask about how to handle escaped defects, product support items, etc...You know, the "unplanned stuff"? Many times they get paralyzed by the idea that "no changes should be made to the sprint that endanger the...

Read More