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.
