Sprints Cost How Much?

A few years ago I was one of several coaches supporting a massive SAFe Agile Release Train (ART) of 35 teams. Forgetting that size dysfunction, during one of the Product Increment (PI) Planning events, for 6 Iterations, I managed to silence a room of about 500 people with two sentences.

“Product Managers and Owners – you are about to plan over $12,000,000 of spending. Make sure you prioritize appropriately.”

Teams are not free

I’m continually surprised by the number of Product Owners, Scrum Masters and others who do not know their cost per Sprint.

Through research and experience working in the United States, a Scrum Team of about 8 developers, the Product Owner and Scrum Master, with a little extra for management support, would cost somewhere between $50,000 and $70,000 per 2 week Sprint. Obviously some locations would be higher as labor costs are much more. For this article I will use a team cost of $50,000 per Sprint.

Scrum reduces cost risk

Traditional Project Management address cost of a product or project by doing a lot of up front work. Analysis, Design and in-depth estimation efforts are used to project a total cost for doing a body of work. As a former developer of 20+ years, having done many of these estimates, I know they are riddled with assumptions, guesses and massive amounts of padding. Yet somehow the vast majority of these projects overrun cost by very large amounts.

Going forward with these estimates are, essentially, placing a very large bet that your idea of value received from doing the work is correct. The downside is that we will not know until many months or even a year or more later, if your bet will pay off. That is an example of high cost risk.

Using an iterative approach such as Scrum reduces the risk by doing work in small increments and reassessing the effort at the end of each iteration during the Sprint Review. Or at least you should be re-assessing value during the Sprint Review, was the value worth the spend, but many teams do not.

The most common Sprint length is 2 weeks. So you are essentially placing small, 2 week bets rather than one very large bet. At the end of each Sprint the team can course correct, or even stop, as necessary. This is an example of lowering cost risk.

But those small bets are not free. Though they are lower risk they still represent considerable cost, $50,000 per bet in this case.

Calculating Sprint Cost

You could go about asking everyone on the team their salary but I bet that won’t go so well. It would also miss overhead costs that the company is actually paying. Things like insurance, taxes and, for companies working on-site, location costs.

Work with management and/or HR to determine an average fully burdened cost for employees within the job class ranges within the team. You might even be surprised how much higher the fully burdened cost is when reflecting on your own salary.

Then simply multiply the number of people on the team by the cost per Sprint duration (for 2 week Sprints use 1/26th of the fully burdened cost per person). Don’t forget to add in a percentage for management support and other potential dependencies that are recurring for people not considered part of the team (perhaps legal support or DBAs from another department).

You won’t get an exact amount but you will get close enough for these purposes. Be conservative, round down when in doubt. That way no one can dismiss your data with concerns of inflating costs.

Examine processes for waste

An in-depth process examination is beyond the scope of this article. However, teams are already likely uncovering process waste within their Retrospective conversations. For problems that are within the team’s control, fix those as quickly as possible.

For issues that are beyond the team’s ability to change, collect data on process waste. How long are work items blocked for outside dependencies? How long are work items waiting for some sort of review or approval? How much time is spent on rework?

Measure and track time lost to any blockage or waste discovered. Calculate the percentage of time wasted against the total Sprint capacity. Now determine the actual monetary cost using that same percentage.

That value is a key piece of information when approaching management to assist with systemic issues.

Benefits of knowing Sprint cost

  • Prioritize appropriate value – A lot of teams get caught up in what is known as the Build Trap, also referred to as becoming a Feature Factory. These are teams, and teams of teams, that just continually crank out Features without regard to the cost of development or return of value. They are not prioritizing expected return against cost. If your next Feature isn’t expected to return at least 3X cost, ask if it is worth doing.
  • Gaining management support – if you are having difficulty gaining management support to address systemic issues start talking money. Look at the delays and wait times within your processes. Explain how that is consuming a percentage, perhaps even over half, of the per Sprint cost. Look for blockages and other constraints – determine the percent of time lost (waste). Showing that, for $50,000 Sprints, $20,000 of the spend is pure waste can be an effective strategy for getting management to fix systemic issues. When you talk money, management listens.

Wrapping Up

We all intuitively know that Scrum teams are not free but most teams do not go any deeper than that. They continue to push Features through the processes without regard for value received against cost. By understanding per Sprint cost, Product Managers and Product Owners gain another tool in their prioritization arsenal. Knowing and using your cost per Sprint is a very effective tool.

If you’d like to learn more about Feature Factories and what can be done, I highly recommend the book Escaping the Build Trap by Melissa Perri. It goes far deeper and explains more strategies than can be covered in a single article.

If you’re looking for a lever to gain management assistance or support for implementing changes, consider using monetary waste within the Sprints. Senior management will likely listen if you can demonstrate hard money being lost to waste each and every Sprint. Explain how much more they could deliver by fixing these issues. I’ve found that talking in dollar waste rather than hours of waste is a more effective strategy to get attention.

There are very few companies that aren’t having some sort of “cost saving” efforts going at any given time. Leverage that angle to gain support for change efforts.

If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.

Until next time!

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Prev
Scrum: On Carryover

Scrum: On Carryover

The misconception, or misunderstanding, is one of math, not effort

Next
Count Stories, Not Points

Count Stories, Not Points

If you're still not convinced, create a scatterplot of the SP estimate and

You May Also Like
Total
0
Share