Many people assume that budget estimation for agile projects is impossible because of the nature of agile projects, which is wrong.

In some cases you really don’t know the full scope of a project on its inception. This fact is the same for all waterfall projects, as well as for the agile projects, so it’s an incorrect assumption to claim that this is the main reason why agile projects can not be properly budgeted upfront.

The budget estimation before the actual work is done, is always “guess”-based. The error in budget estimation depends on the experience and the risk associated with the particular project at hand.

There are seven steps that can assist you to estimate an accurate budget for your agile projects. You should take these 7 steps prior to the first iteration of the actual agile methodology kicks off (it is supposed that you use Scrum methodology).

1. Define the requirements

Defining the requirements is a risky step, since you might miss some functionality in the list. You should complete this step carefully, and to talk 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.

You can involve a business analyst or subject expert in your analysis. E.g., if the goal is to develop a new accountancy application, you can invite experts – accountants over to define some critical questions, which together by the product owner may produce additional requirements. You should conduct several meetings, and to continue the conversation after 2-3 days to see if a fresh mind can give you some extra information (requirements). Also include the alarms and notifications at this stage. You can discard them later on, but at this stage – it is better to be on a safe side.

In Scrum methodology, as a result you will get a list of user stories, potentially accompanied by some epics that need to be split further – into user stories at a later phase.

2. Practice planning poker with your team

There is a technique called “Planning Poker” that you can use it – to estimate the requirements in a relative way. This technique will give you a list of requirements with their respective estimations, but these are not completely connected to the concept of time. You should sum all the points/ scores to obtain the complete effort for the software development.

3. Estimate your speed

You should estimate how many requirements (user stories) you can do in one iteration (sprint). You can do this together with your team, when you are estimating how many items will you complete in 1 iteration, or it can be based on the past data – from previous projects (of the same team). E.g.: if your team is doing 15 points per iteration, the velocity of the team is 15.

4. Calculate the sprint burn-rate

You should discover the cost per developer for a single iteration, based on the actual or average fully-loaded developer cost. You can get these data from your HR or financial department.

If this cost is known on a yearly basis, you can estimate the cost of one iteration (two weeks), by dividing the total cost by 26. If you have only single developer – this will give you the cost for a complete “mini”-Sprint. You will get the burn rate for a real sprint, if you multiply this with the number of developers.

5. Burn rate and the velocity will help you to find out the cost of the total requirements

Let’s assume that your total requirements will cost 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 it will take 10 sprints to finish the project; the iteration with five developers will cost $15000, and the total development cost will be about $15000 x 10 = $150000.

6. Identify non-development costs by value stream mapping

This technique will assist you to determine the additional costs, besides development costs. These might include: consultancy, training, management (interim sprint costs), software licenses, hardware expenses (servers), etc.

7. Put everything together, including your risk factor

The risk factor of the project could be between 30%-65% and is very affected by a number of elements, such as: the experience you have with the above methodology, the experience the team has with planning poker estimations etc. The total costs, increased by the risk factor will determine the budget that you need to get the formal approval for.