Agile budgeting

Combining the incombinable

“Budgeting agile projects is impossible because of the nature of agile projects”

Wrong.

It’s true in some cases that you don’t know the full scope of a project on day one. This fact is no different with waterfall projects than it is with agile projects, so it’s basically incorrect logic to claim that this is the main reason why agile projects can not be properly budgeted upfront.

ANY estimation or budget given before the actual work is done, is always an educated “guesstimate”. The fault tolerance of the budget depends on the experience and the risk associated with the particular project at hand.

See also my article about “The Cone of Uncertainty”.

A suggested approach

I’ve learned that the following seven steps will get you as close as possible to an accurate budget for your agile projects. All of these steps take place before the first iteration of the actual agile methodology kicks off (i’m using Scrum in the examples below).

Step 1 : List all the requirements

This is already one of the more risky steps as you might forget to include some functionality. So don’t do this overnight, but sit down with the product owner (as defined by Scrum) to go over the list of all the desired features and figure out ways to find out if you’re missing some.

Some suggestions:

1. Include subject matter experts in your conversations. For example: if the objective is to develop a new accountancy application, invite some accountancy experts over to come up with some critical questions which, when answered by the product owner, might uncover additional requirements.
2. Don’t stop after a single meeting, but continue the conversation after a couple of days to see if a ‘fresh mind’ gives you some additional input.
3. Also include the ‘whistles and bells’ at this stage. These can always be discarded later on. At this stage it is better to be “safe than sorry”.

In Scrum terminology, the result of this step will be a list of user stories, potentially accompanied by some epics that need to be broken down further into user stories at a later phase.

Step 2 : Play some Planning Poker with your team

Use a technique like Planning Poker to score the requirements in a relative way. The result will be a list of requirements with their respective estimations, but these are not yet attached to the concept of time.

Sum all the scores (‘points’) to get the total estimated effort for software development.

Step 3 : Know your Velocity

Figure out how many requirements (user stories) you can do in one iteration (sprint). This can be done by sitting together with the team while you go over the list to see how many items fit in one iteration, or it can be based on historical information of previous projects (of the same team).

Example: if your team can do 10 points per iteration, the velocity of the team is 10.

Step 4 : Calculate your sprint Burn Rate

Find out how much a single iteration costs per developer, based on the actual or average fully-loaded developer cost. Your HR or Finance manager can help you out with this.

If you know this cost on a yearly basis, divide it by 26 to figure out the cost of one iteration of two weeks. This is the cost of a sprint with only one developer. Multiply this with the number of developers, and you get your sprint burn rate.

Step 5 : Use the sprint Burn Rate in combination with the Velocity to find out the cost of the total requirements

Let’s say that your total requirements set costs 100 points and that your team has a velocity of 10 points per iteration and that one two-weeks sprint costs €3000 per developer.

This means that:

• a single iteration with 5 developers costs €15000
• it takes 10 sprints to complete the project
• the development cost will be approximately 10 x €15000 = €150000

Step 6 : Use Value Stream Mapping to identify non-development costs

Using this technique will uncover any additional costs, besides development costs. These might include:

• training
• consultancy
• overhead (management, ‘in-between sprint costs’,…)
• software licensing
• capital costs (servers, …)
• …

Step 7 : Add everything together, including your risk factor

Your risk factor might be anything between 20%-70% and is highly influenced by a number of elements:

• how much experience do you have with the above methodology?
• how much experience does the team have with planning poker estimations?

The sum of all the costs, uplifted by the risk factor will get you the budget that you need to get the formal approval for.

Alternatively: Use the Cone of Uncertainty to help you determine an appropriate risk factor.

Alternative approach

You might take a different approach by doing one or two actual sprints and use this as a reference to determine the remaining cost of the project. This assumes however that you take on the more risky items first so that you feel comfortable about the rest of the work. After all it’s only getting easier to estimate since the risk factor will be reduced.

This will allow you to do steps 2 and 3 more accurately, but assumes that the organisation is prepared to take on costs before the actual budget approval.

Stefan Luyten

More information: http://www.triton-consulting.be