We are all familiar with the concepts of budgets right? Spend less money than you make, eat less 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 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 will acknowledge the work a team needs to do so that prioritization exercise takes place. Invisible queues are our enemy. I like to teach teams that there are really only 4 categories of backlog items (you can sub categorize however you wish or even rename the items).
- Roadmap
- Minor Enhancements
- Defects
- Engineering/Maintenance
Roadmap backlog items are those things that are visible bits of work you want communicated to your customers and outlines a plan for your product. It is also ok if those things have dates that are associated with the timing of releases.
Minor enhancements are those 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. It can also be feedback loops that you are building in to 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 one 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 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 complete last quarter or last year and build a budge based on that knowledge this year (and of course take into count 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. Same way with 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 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's are spending their 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.
