Why Organizations Need Answers About Project Delivery
I hear it all the time. The organization wants to know when is this work going to be done? How much does it cost? How are we looking? And they have every right to know the answer to those questions. I doubt anybody in this world would sit down and write a really large check to a team of people and say, I don't care when everything's done. Just go do the best you can and come back to us.
My experience has been most organizations need to have some prioritization technique and some understanding of what it is that we want to work on.
Hi, my name is Lance Dacy, otherwise known as Big Agile. And I'd like to talk to you today about how can we put techniques in place to properly manage our team's capacity and be great stewards of that capacity.
The Foundation: Sustainable Pace and Capacity Management
I'm reminded of Agile principle number eight. It talks about how we want to ensure that the processes that we put in place arrive at some way for the team to have a constant sustainable pace indefinitely as they work on items. And what that really starts with is, yeah, the team needs to be a good way of scoring their capacity and only pulling work into their system that they can manage.
That takes a lot of effort to teach them how to do that, but I really think it starts upstream with a product owner working with their stakeholders and properly prioritizing work in some cadence that's longer than a sprint, maybe like a quarterly planning session and making sure that we don't plan so much work that the team has to work over time to deliver it.
So there's a lot of systems in play here, and we could go on and on and on about these, but really what I want to talk about now is a great steward of the team's capacity should start with the product owner. And if you don't know how much capacity you have to spend, it's very difficult to make those decisions.
Team Capacity Management: Like Your Personal Budget
So we're going to talk about today how your team's capacity is very similar to the way that you manage your personal budget every month. I doubt anybody listening to this makes an infinite amount of money every month. So what you typically have to do is predict how much money is going to come in that month. And if you're self-employed, sometimes that's a harder exercise than those of us who have a steady job and got the same pay for the last year. So you want to take that empirical data and say, okay, in the next period that I want to plan, how much do I think I'm going to get?
And so if you're like my family, my wife and I, we've been married a long time. We have four children. If I let my children prioritize where we spend our money, we wouldn't be in the state that we are now. But if my wife and I didn't have a good level of discipline and rigor, well we'd love to travel, so we would just blow all of our money on traveling.
So I think very similar stakeholders and product owners need to get together periodically and determine how much capacity do we have to plan and where are we going to federate that capacity over these larger buckets of work.
The Four-Theme Budgeting System
So just like in your personal budget, you have clothing and groceries and maybe mortgage and insurance, you have to budget for those activities. And then the leftover, you get to do maybe the fun stuff. So your stakeholders typically want to do the fun stuff. They want the new feature, the shiny objects, all the great things that they think are going to sell our product. And who wouldn't want that?
But if you're running a technology team, you cannot spend 100% of your team's capacity on the fun shiny things to do. So in our product owner course, I typically bring up a nice little budgeting system that this is a real team that I've used in the past and say, every new backlog that I manage is going to have four themes, brand new file, new four themes, I call 'em:
1. Roadmap Items
Roadmap items are typically those nice shiny fun things that we want to do for our clients.
2. Minor Enhancements
Minor enhancements are more like discretionary spending for the product owner. So there's going to be some amount every quarter that they reserve that's going to be small quick wins. They don't have to go really get the stakeholders aligned on these things. We've launched a feature, they want to move something around. We should be at liberty to do that. So we trust our product owner with a certain percent of the team's capacity to be agile.
3. Defects
No matter how good you are, you're going to have defects.
4. Engineering and Maintenance
And then the last one that's really often overlooked and can turn into this very well-known term in our industry called technical debt is really just the mismanagement of the engineering and maintenance of the product. Now, technical debt usually is the intentional and deliberate decision. That's what debt is. You go into debt so that you capitalize on an opportunity sooner than if you had the money. So technical debt's kind of the same way, but there's many different variations of how technical debt can manifest. I'm just going to call a majority of those activities, engineering and maintenance.
And what that really means, if you own a car and you're the product owner of the car, the people who built the car give you a manual on how to maintain it, I think our developers should do the same thing. So I need to set aside money periodically to ensure that that machine and that technology is operating at the best that it can be. And so that requires a great deal of expense. So I want to make sure our stakeholders are aware they cannot prioritize 100% of the capacity of the team.
Calculating Team Capacity Using Historical Data
So if you do quarterly planning and you follow a process like Scrum, the good news about Scrum is we're going to have this historical metric lagging indicator called velocity, which is most useful over a handful of sprints. But in a quarter I can say, well, if my team accomplishes 80 points of sprint on average and there's six sprints in a quarter, we do two week sprints. Well, I know now that I have about 480 points of capacity the team can spend.
Now, I'll always get their input and say, is four 80 sound pretty good or is there anything we need to adjust for? If the team's operating fairly well, they may just say, yeah, that sounds like a good number. So that's the beginning point of helping them operate at a constant sustainable pace.
So what we're going to do then is decide what percent of that 480 need to be allocated to minor enhancements, defects, engineering and maintenance. Whatever is left over is what I take to my stakeholder session to align them on the priorities.
Prioritization Techniques: Relative Weighting
Now, there's a lot of different prioritization techniques out there in the world. One of my favorite is relative weighting, which essentially allows us to prioritize the high value items based on their cost. I'm a big fan of realizing that I can't prioritize the business value of something until I know the cost.
So we basically just come up with a roadmap listing of items. We have a good way for our stakeholders to align on how much that backlog item affects the overall business objective OKRs or whatever. And we score those on a scale of one to nine. Now, we teach this in our product owner class, so if you want to learn more about that, feel free to join us.
But essentially this is what it looks like. And once I have that and the cost of the item, I can derive a good prioritization metric and sort the sheet. And then we can actually have really good discussions as stakeholders. Now, I don't let this data run me at all. We still have good conversations about it, and if we think something's incorrect, we may say, well, we need to wait this category a little bit more, or we don't agree with these numbers, but it's a good starting point to have a conversation.
So essentially that ties all back into our budget and our capacity so that when we look at how much of the team's capacity can go to roadmap, I can just flip over to my relative waiting and kind of draw a waterline here and say, well, we can only do two or three of these items. Is that okay or is that not? So essentially this is really more a facilitation technique.
Understanding Discretionary Spending in Product Management
So roadmap are those customer facing committed things that you're typically used to. Minor enhancements are discretionary spending for the product owner. My wife and I share our monthly budget together, and this morning I drove out to the coffee shop and got a $3 and 18 cent cup of coffee. I didn't ask her if I could get that or not, but that's probably a bad thing. If we're sharing a budget, she has to have knowledge. But the point is we trust each other with a certain amount of our budget every month. So we call that discretionary spending. She has a certain amount that she can go spend that I ask no questions about. Same way with my spending. Sometimes she'll ask questions about that. But all that to say is that allows us to be more flexible.
But now I didn't call her this morning and say, Hey, come look at the new Cadillac Escalade I bought. It's sitting out in our driveway. That would be a big problem. So those are like roadmap things. We have to come together and really agree on those.
Implementing the Capacity Management Framework
So whatever you want to call these, maybe start out trying to figure out what's your recurring amount of work that you think your team can do? And every quarter try to put a number on that. And there's a lot of different ways to use data to predict that. But all that to say that helps us do a better job with our stakeholders on how much is going to roadmap, minor enhancements, defects, and engineering and maintenance. And that can fluctuate all throughout the quarter.
But then that allows your team, you can say, this is the amount that we have this quarter to spend on engineering and maintenance. Let your developers go write those backlog items, prioritize 'em sort, and it kind of minimizes the product owners need to understand all of those items. I'm not saying you don't understand them, but I don't want to write a backlog item for something that I have no idea what it is. So let the team own all that. Let them own the maintenance of the car, if you will, and you just partner with them and say, what'll happen if I don't do that this quarter? What if we push it to next quarter?
And so it just gives you a really good way to collaborate with your stakeholders and your team. So hopefully that'll help you and your prioritization techniques. And we hope to see you again sometime soon.
Take Your Product Management Skills to the Next Level
Ready to master these capacity management and prioritization techniques? Big Agile offers comprehensive product owner classes where you can dive deeper into relative weighting, capacity budgeting, and advanced stakeholder management strategies. Our courses provide hands-on experience with the frameworks discussed in this article, helping you become a more effective steward of your team's capacity. Explore the classes that Big Agile offers and transform how you approach product management today.