Reading: Agile Budgeting: How to Calculate For Agile Teams
Save for Later
A common concern I get from Agile newbies is:
“How do I calculate the cost of my Agile project if I don’t do all the up-front planning?“
Actually, it turns out that when I leverage agile00 methods to simplify my project accounting, budgeting becomes much easier. I’m going to show you two approaches that leverage two powerful attributes of Agile projects and help calculate budgets for Agile teams.
Powerful Attributes of Agile Projects
Stable Team Roster
Project managers across the world agree that a key risk for any project is getting your people yanked off the team, or having new people thrown onto a team only at the last minute. This is the evil version of “Resource Leveling”, and it prevents any reliable forecast of a project burn rate. So, let’s see what happens when we request, nay demand, a stable team roster.
Time-boxed Iterations
Rather than try to calculate the budget for Agile teams across 12 months, I want to simplify my problem. If we work in 1-month time-boxed iterations, I only need to calculate the budget of a given iteration. Let’s see how that works below.
Approaches for Calculating Budgets for Agile Teams
Using a Blended Rate
When I worked at Marriott International HQ outside of Washington DC, project managers did not have visibility into the people’s compensation. Instead, we used a common “blended rate” of $125/hour. HR estimated the total loaded cost of the organization came down to that one number. Let’s assume I have a team roster of 12 people, but 4 of them are half-time, yielding a total of 10 Full-Time Equivalents (FTEs).
=> $125 X 8 chargeable hours per day = $1,000 fixed burn rate per person per day.
=> $1,000 X 10 FTEs on my team = $10,000 fixed burn rate per day.
=> $10,000 X 10 chargeable days in a 2-week iteration = $100,000 fixed iteration burn rate.
Using Specific Labor Categories
In other organizations, the Project Manager has to capitalize labor costs according to specific categories. For that we can’t over-simplify the problem with a blended rate.
=> Annual loaded cost of each team member / number of theoretical iterations in a year = fixed burn rate per iteration for that team member
=> Sum (every team member’s specific fixed burn rate per iteration) = fixed iteration burn rate
In the example below, I run these calculations to derive a $19,350 fixed burn rate per iteration.
Sample team costs
So What?
Having a fixed, reliable iteration burn-rate is killer. Once I have that budgetary metric, I finally have some compelling talking points around common conversations:
- “Mr. Client, our agile release planning session says the ‘social media’ initiative will take 5 iterations, totaling $250K. Is the projected upside worth the cost?”
- “Yes, Ms. Vice President, we can add that emergency feature. However, the team says that will take another 2 iterations costing $100K. Can you authorize the additional budget?”
- “Team, we have to be ruthless about bugs. Any bug that prevents us from going live will cost us $50K in an extra iteration, and I don’t want that coming out of my annual bonus.”
…or use the metric to argue against common project mistakes:
- “Sure, you can take the senior tester off my project. But that will cause my current iteration to fail at a cost of $50K. Plus the team feels it will add another 30% risk of missing the deadline for the remaining $200K worth of work. That puts the totalfinancialimpact at $50K + (30% x $200K) = $110K. Are you prepared to eat those costs as well?
- “I know we are falling behind, but If we extend the iteration until we feel we are done, I have no way of forecasting the financial impact. However, if we simply extend the project by one extra iteration, I can tell you it will cost exactly $50K.”
What about you? Have you found Agile projects to be easier or harder to budget?
Next› Transforming Mountains
Up Next:
Comments (24)
Mark Culmer
ReplyHi
Good post. I have been using this approach for my agile projects since 2010 and it works really well.
Still, even though it’s so simple, some people still don’t get this approach.
Thanks
Reply
Joe Astolfi
ReplyHi Jesse,
Great, straightforward explanation on agile budgeting. This is the same method I use to estimate agile initiatives. One of the key considerations is that the team members are dedicated to one team, or as dedicated as possible. The fallacy is still persistent that it is a good thing to slice up people’s time across multiple initiatives. We still haven’t acknowledged the amount of waste that occurs during context switching.
The one thing I do differently than your example is estimate less than 100% allocation for an organization’s employees. This is to account for training, time off, org meetings, and other events that do not result in charges to the project’s budget. I typically pick 80% as a guideline unless I have better information from the organization.
Thanks for posting this in such a clear and concise manner.
JoeReply
Jesse Fewell
ReplyMark, thanks for the comment. The reason many people don’t get it, is because we haven’t been trained this way. Continue being successful, and being patient with those who wonder how you are so successful :)
Reply
Jesse Fewell
ReplyJoe, good point about the 20% allocation of non-chargeable time. My example refers to organizations that bake those costs into the blended rate or loaded cost. Your explanation extends the calculations to yet another model. Many thanks for the comment.
Reply
Alan Gladman
ReplyI love the post; extremely well put Jesse. In large multi-nationals like ours we use a blended rate for each country, and its not the easiest thing in the world uncovering that kind of information, but it is available. I’ve been suggesting to Scrum Masters and PMs alike that they at least need to understand the cost of a story point and they get that from a very similar calculation. That way, when the product owner considers the business value of a particular story, or the worth of another release, they can understand the real cost.
Reply
Jesse Fewell
ReplyAlan, thanks for the kind words. I totally agree that cost-per-story-point is a helpful metric. However, I would not broadcast that metric widely. I would only use it as an internal metric to convert the size of a given backlog item (story points) to the sticker price for a backlog item (dollars). That way, the team isn’t measured by arbitrary interpretations of utility metrics like story points. However, your point is inspiring a new blog post…Hmmm.
Reply
Samar Elatta
ReplyI really like this approach a lot. Thanks for sharing. I’ve been using a similar appraoch but doing release planning initially using this rate in order to estimate the total cost of a project since the organizations I’ve coached needed to have the total cost up front.
Reply
Jesse Fewell
ReplySamar, Thanks for the comment. I totally agree with you in that most organizations have an honest question regarding “how much will it cost?” Usually the real question is “how much budget should I allocate to your project?” It drives me crazy to hear agile experts refuse to answer that question and demand dynamic funding models. Granted, it would be ideal to have monthly, or even quarterly funding cycles, where every PM or Product Owner must make the business case for more iterations. But in the dozens of companies that I’ve seen, that almost never happens. Instead, I’d rather work within the system to be given *some* money, and then deliver the most value possible within that constraint.
Reply
Mark Gustafson
ReplyI just left a small software company where for a mature and stable scrum team with a well established velocity, we were able to actually deliver custom code to our customer that requested it (we typically don’t like to do custom work) for a price based on cost per story point (with proper mark up for commissions, profit etc.)
I’m now heading up IS development for a larger public company that has strong budgeting process in place. This article will help me greatly as I introduce SCRUM to our dev process!
Reply
Jesse Fewell
ReplyMark, thanks for the kind words. Cost-per-story-point is a great metric to use to convert a team’s internal planning metric (story points) into a stakeholder-facing metric (sticker price). However, be careful not to expose that metric to senior management. They will be tempted to use it as a performance metric, and drive the it lower as a means to control costs. Instead, focus on your reliability with a fixed burn rate and stable velocity.
Thanks again for the comment.
Reply
Graham Carey
ReplyJesse regarding your two previous points:
1) Agree totally about delivering the “most value possible within” the constraint of the given budget. That really is the link to the lean philosophy of the Minimum Viable Product.2) I disagree somewhat about not revealing story points to management. I am a huge fan of transparency and, therefore accountability. For too long software development has been seen as being hidden behind an (often seemingly) inflexible, black hole. Agile is helping this but it can still go further. Software needs to become more accountable and having transparency around allocating cost to story points are a great way for doing this. This can also be a good way to stop management introducing scope creep.
Reply
Jesse Fewell
ReplyGraham, fair enough. I do agree that putting a sticker price on backlog items will make the business think twice about all those last minute additions. I’m also totally fine with broadcasting the conversion metric (cost-per-story-point) if that creates more transparancy and open conversation in your organization. However, I’ve seen it backfire more than once: “Why isn’t your velocity increasing the standard 15% every iteration?”…”You really need to get your cost-per-story-point down to $1000 in order to achieve our PMO efficiency goals”….”why doesn’t your team just estimate in mandays? It seems convoluted to estimate in false units and then convert back to labor cost.”
In the end, I believe “balance” trumps “transparency”. Well done on creating a culture of openness, but other teams may find they have to manage the amount of overbearing culture seeps into their their internal culture.
Reply
John
ReplyI agree with Jesse. The reason why story points should not be directly mapped to labor cost is because story points are ‘relative’ sizing. if you are using Fibonacci numbers, the amount of effort between a 2 and an 8 , the 2 doesn’t necessarily translate to 4 times the amount of work of an 8 .
The relative sizing allows estimation of work to be more accurate by comparing the weight of a point which can be measured by a historical benchmark. By associating story points to explicit labor cost/hours/days, you are losing the benefit of relative sizing and making it explicit which is more prone to error in estimation.
Reply
William Boon
ReplyGood Post. I think it’s the first time I’ve seen this explained so simply and clearly. It is worth noting that at the end of day we are still, as always, dealing with estimates. Having a killer burn rate makes the figures more real. The problem is that the burn rate will fluctuate – it’s the nature of the beast. Unless you’re doing Agile for a quite a long time it can be hard to achieve this. Even if you do have a reliable burn rate be prepared for the occassional conversation with the managment/client when it spikes and it starts costing more “than you told it would cost”
Reply
Jesse Fewell
ReplyWilliam, thanks for the kind words. Regarding the unexpected costs incurred during an agile transition, I think you’ve brought up a point that I think merits a full post of its own. Stay tuned…
Reply
Arunkumar
ReplyJesse Fewell
Thanks for this wonderful posting. This gives us a good understanding of how costing can be done for Agile projects. THe document is very simple and easy to understand. Keep posting more.
Thanks again!Reply
Jesse Fewell
ReplyArunkumar, thank you for the generous comment. If you keep commenting more like this, I’ll keep posting more :)
Reply
Donna Woodruff
ReplyThis is not very different from some of our current estimating and forecasting process we follow today for our projects that are predominantly Waterfall. I’d like to know how do you estimate the Non-labor and External Labor costs? Currently we forecast based on when a project is approved. (Hardware, Software, Statements of Work, etc). Labor is the easy part I think. Thoughts?
Reply
Swati
ReplyIt’s a great post. I would like to know how you have calculated the fully loaded cost in second approach.
Thanks
Reply
Asad Jobanputra
ReplyI don’t have dedicated teams. I have dedicated staffing levels for any given sprint, but I have to share my team with other initiatives (supporting old products, new product development, customer customizations).
How would you adjust this approach for budgeting given dedicated teams and iterations but not having the same level of staff throughout the project/year?
Reply
Sarth
ReplySo, basically this makes it a resource-based budgeting model rather than a deliverable-based Fixed price model.
This makes sense also because Agile never emphasizes on complete set of requirement specification document before project work starts.Thanks for the blog post.
Reply
Jeremy Dees
ReplyI’m being introduced to this method and I’ve never had any training on Agile it Lean Budgeting. I’m excited about what I am about to learn.
Reply
primavera p6
ReplyUses of resources can closely be monitored by Project Managers within Oracle’s Primavera P6, and generate forecasts of changes in resource availability. To keep the project on track, project managers identify what other resources may be diverted within Primavera P6.
Reply
Leave a comment
Leave Comment
