Get certified - Transform your world of work today

How to Convince Your CFO to Use Scrum

01/19/2011 by Jan Van den Nieuwenhof

Convincing your CFO or other executive officers in your company to use Scrum is actually very simple, in theory. Try this strategy the next time you need to help executive stakeholders understand why Scrum is an important and useful process for software development.

In my experience, financial experts and managers are very keen on knowing what will happen if certain situations occur and often want to simulate "what if" scenarios as part of their risk management strategy. The best approach in this situation is to compare the business value you deliver to what happens if the project stops early.

There are several reasons software development projects stop before their projected date of completion:

  • Severe company budget cuts
  • A change in project priorities,
  • The company has been taken over
  • The approved budget is not enough for the complete scope of the project

When making a case to management for using Scrum a couple years ago, we posed this question to management: What if the project has to be stopped at roughly 60% of its effort or timeline?

For demonstration purposes, we compared two projects. The first, Project W, is run in a pure waterfall-based approach. The second, Project S, uses an agile approach to deliver the requirements.

Project W has a typical phased expenditure and delivery pattern:

  • 10% of time/effort involves setting up and scoping the project
  • 25% of time/effort is spent on a thorough analysis of the software product
  • 40% of time/effort is spent on development and system testing
  • 20% of time/effort involves bug fixes, and executing integration and acceptance tests and
  • 5% of time/effort is required to put software into production and launch it to customers.

As you can see, if the team is ordered to stop development 60% of the way through the process we would actually be right in the middle of writing the code and executing some system tests. In this scenario, the "value" Project W delivers to the company is in the form of a heap of analysis documents and some untested software.

Now let's take a look at the expenditure pattern of Project S, run in Scrum:

  • 10% of time/effort involves setting up and scoping the project
  • 85% of time/effort is spent analyzing, developing, and testing product increments that are delivered iteratively in bi-weekly sprints
  • 5% of time spent is required to properly close the project

If Project S has to stop at 60% of time or effort spent, the team will already have a good amount of sprints done and will have already delivered some releasable software. In this scenario, Project S delivers real value and marketable features (probably around 40% to 50% of the product backlog) to the customer.

In talking with management, we used an earned (business) value graph to demonstrate to further illustrate our point. It includes the following assumptions:

  • Start-up and scoping of a project / product is worth 0% of the total value
  • Analysis and design documentation is worth 15% of the total value
  • Source code with unit and system tests is worth 35% of the total value
  • Completely tested and packaged software is worth 50% of the total value


Our CFO and other executive officers decided to start using Scrum for our new product developments because they believe that, from a company risk management perspective, it's better to use Scrum than phased development.