Who is creating and managing the budget?
Projects are funded in company-specific ways. Usually, a project sponsor gets funding from a steering committee or the CFO. In other cases, a project may be funded out of a specific department's budget. In all cases, there is ultimately a budgetary authority that authorizes predefined or ongoing spend for a project. Any well-run company has a budget process. This process includes the delegation of formal authority to someone in the organization to manage that budget.On projects that use the Scrum framework, that person should be the product owner. In Scrum, the product owner is responsible for prioritizing the deliverables. By extension, this makes the product owner responsible for the allocation of resources for the project and for creating the initial budget.
Cost per iteration, per team?
The two fundamental features of Scrum projects are that they will have a stable team setup and iterations with a fixed duration -- for example, two-week sprints. When you have these two pieces of information, you can compute the costs per iteration. Sounds simple, but the approach has a few challenges.Let’s start with the team composition. We will assume what is typical for projects in larger companies, which is a mix of internal employees and external contractors and consultants. For each team member, we will need a few pieces of information.
Role: Product owner, ScrumMaster, team member (business analyst, software engineer, tester)
Daily rate: Most larger companies will have a fixed daily rate for internal employees. Based on their level, they will sometimes be different, but typically there is one rate for all employees that includes all costs. External employees will have a daily rate specified in their contract and, when relevant, you should add VAT to this rate to get the real cash-out costs. When you have not yet fixed the rates of the external employees, you will have to estimate them. I prefer to take a range and create a low-cost and a high-cost projection of one iteration.
Allocated time on project: In an ideal world, the team members are working full time on this project, but this is often not the case. We will have to determine the percentage of their time that they will be working on this project.
Burn rate per sprint: This is the cost that this team member will incur per iteration, under the assumption that he or she will work the agreed allocated time on the project. I always assume 20 working days per month for budgeting. In this example, it's ten days per two-week sprint. I know that people who are allocated 100 percent on the project will not work 260 days a year. Typically this will be around 220 days a year (Switzerland and other countries will have fewer or more days off).
Internal/external: For computing the cash-out in your budget, you will need to identify which costs are internal and which are external.
Example of internal and external costs for a team:
When you are budgeting a larger project with multiple Scrum teams, you just do this exercise for each team. I budget them separately, which means I will have a line in my budget for each team and do not have a total cost per iteration. This is because not each team will have the same number of iterations.
When your project includes a project management office (PMO) resources, such as a chief product owner or a program manager, you can do two things: create a separate team for them and do exactly the same exercise as above, or add each one of those resources for a certain percentage to an existing Scrum team. I have seen both, but I prefer the first one and call the team "Program Management." This way, it is very clear that they are managing and not building, and you prevent long discussions regarding team percentages.
One other team that I have added to some budgets is the Initiation team. Before everything is in place for a larger project (including a final budget approval), a small team starts the initiation and elicitation of the project. And yes, I let this team work in sprints as well. Why?
1. Management is not willing to commit to starting the project without having a view of the total scope and cost.
2. A business case is required to make a decision whether to go ahead with the project at all.
3. Multiple stakeholders must agree on the scope of the deliverables for the project before it is sanctioned.
Example of internal and external costs for a team:
| Role | Daily rate | Allocated time on project | Internal / external | Burn rate per 2-week sprint |
| Product owner | 1000 | 50% | I | 5.000 |
| ScrumMaster | 1400 | 100% | E | 14.000 |
| Business analyst | 1200 | 100% | E | 12.000 |
| Software engineer 1 | 1000 | 100% | I | 10.000 |
| Software engineer 2 | 1000 | 100% | I | 10.000 |
| Software engineer 3 | 1200 | 100% | E | 12.000 |
| Tester 1 | 1000 | 100% | I | 10.000 |
| Tester 2 | 1100 | 50% | E | 5.500 |
| Total | 78.500 | |||
| Total internal | 35.000 | |||
| Total external | 43.500 |
When you are budgeting a larger project with multiple Scrum teams, you just do this exercise for each team. I budget them separately, which means I will have a line in my budget for each team and do not have a total cost per iteration. This is because not each team will have the same number of iterations.
When your project includes a project management office (PMO) resources, such as a chief product owner or a program manager, you can do two things: create a separate team for them and do exactly the same exercise as above, or add each one of those resources for a certain percentage to an existing Scrum team. I have seen both, but I prefer the first one and call the team "Program Management." This way, it is very clear that they are managing and not building, and you prevent long discussions regarding team percentages.
One other team that I have added to some budgets is the Initiation team. Before everything is in place for a larger project (including a final budget approval), a small team starts the initiation and elicitation of the project. And yes, I let this team work in sprints as well. Why?
1. Management is not willing to commit to starting the project without having a view of the total scope and cost.
2. A business case is required to make a decision whether to go ahead with the project at all.
3. Multiple stakeholders must agree on the scope of the deliverables for the project before it is sanctioned.
Example of internal and external costs for multiple teams:
After I have the cost per sprint, per team (including the overhead team, as shown in the example), I can start the next step.
When we have this information, we can compute the total project budget for each team. When the project runs over multiple calendar years, you will have to split the numbers by year. This means that you count the sprints per calendar year for each team.
Example of total project budget for each team:
But unlike in Waterfall projects with detailed requirements specification, Scrum embraces this impossibility, so the initial estimates in Scrum are not fixed. They become more realistic over time. As soon as the project starts, the requirements and general conditions become clearer with every passing sprint. And by using proven estimation methods and gained experience, the team becomes better at telling how much a desired feature will affect the budget. After just a few iterations (which is very early in the course of a bigger project) the project sponsor has reliable and valid information about the required budget.
Besides creating a more reliable budget by design as part of the Scrum process, Scrum projects guarantee transparent budget control on the way. Cost explosions, which might need to be accepted in a Waterfall project if you want to actually see your software in the end, can be avoided with Scrum. The project sponsor will still receive a high-quality software product, albeit with fewer features than initially planned.
1. If meeting all requirements is expected to cost more than budgeted, the project sponsor can abort the project at an early stage. A basic version of the project is generally released after just a few iterations.
2. The project sponsor can let the project run until the planned budget is consumed and then suspend or terminate the project. In any case, they will have functional software that contains the most important functions.
3. The project sponsor has the option of changing the project scope by postponing or omitting less important functions.
4. The project sponsor can increase the budget.
Scrum allows the project sponsor full budget control and thus full flexibility while reducing the risk of cost explosions because of big-bang implementations.
This article appeared first on ScrumAlliance.org
Posted on Wednesday, August 12, 2015 by Henrico Dolfing
| Team | Total costs per 2-week sprint | External costs per 2-week sprint | Internal costs per 2-week sprint |
| Initiation | 20.000 | 20.000 | |
| Overhead | 24.000 | 14.000 | 10.000 |
| Team A | 78.500 | 43.500 | 35.000 |
| Team B | 56.000 | 16.000 | 40.000 |
| Team C | 94.000 | 74.000 | 20.000 |
After I have the cost per sprint, per team (including the overhead team, as shown in the example), I can start the next step.
How many sprints per team?
There are thousands of articles and videos on Agile estimating and planning, so I will not address how you can do this here. What we will need from each team for our budget is the number of sprints that are planned. This can be done by estimating the product backlog and dividing it by the team's (estimated) velocity. You will not even have to do this for some projects because the time is fixed, and you know the maximum number of sprints up front. The overhead team has always the same number of sprints as the team with the largest number of sprints.When we have this information, we can compute the total project budget for each team. When the project runs over multiple calendar years, you will have to split the numbers by year. This means that you count the sprints per calendar year for each team.
Example of total project budget for each team:
| Team | # sprints 2015 | # sprints 2016 | Costs 2015 | Costs 2016 | Total costs |
| Initiation | 2 | 40.000 | 0 | 40.000 | |
| Overhead | 12 | 18 | 288.000 | 432.000 | 720.000 |
| Team A | 12 | 12 | 942.000 | 942.000 | 1.884.000 |
| Team B | 8 | 18 | 448.000 | 1.008.000 | 1.456.000 |
| Team C | 10 | 8 | 940.000 | 752.000 | 1.692.000 |
| Total | 2.658.000 | 3.134.000 | 5.792.000 |
Are there any additional costs?
This answer will be "Yes" for almost every project. Additional costs are incurred through local hardware and software for the software engineers and testers as well as the infrastructure for the final project. Development environment, test environment, user acceptance testing environment, and production environment will cost money to buy, set up, and maintain. I do not allocate these costs to a team when it is not forced by accounting. I will add a line for hardware, a line for software, and a line for setup costs (typically an external IT provider or internal IT costs). Other possible costs are travel (for example, one team is at a different location), workshops, and training. Again, these are project costs and not team costs.How about contingency?
Most companies I have worked for have an obligated percentage of contingency on top of the total budget, or parts of the budget, that typically range from 10 percent to 15 percent. Be careful here, because although you have more money, it is hard to add members to an existing Scrum team. Therefore, this is only usable for running an additional number of sprints.How reliable is the budget?
Unfortunately, serious, realistic planning is impossible at the start of a software project. This is true for conventional and Scrum projects and does not reflect the team or service provider’s capabilities. It is due to the nature of complex IT projects.But unlike in Waterfall projects with detailed requirements specification, Scrum embraces this impossibility, so the initial estimates in Scrum are not fixed. They become more realistic over time. As soon as the project starts, the requirements and general conditions become clearer with every passing sprint. And by using proven estimation methods and gained experience, the team becomes better at telling how much a desired feature will affect the budget. After just a few iterations (which is very early in the course of a bigger project) the project sponsor has reliable and valid information about the required budget.
Besides creating a more reliable budget by design as part of the Scrum process, Scrum projects guarantee transparent budget control on the way. Cost explosions, which might need to be accepted in a Waterfall project if you want to actually see your software in the end, can be avoided with Scrum. The project sponsor will still receive a high-quality software product, albeit with fewer features than initially planned.
Possible reactions to a total budget that ends up greater than planned
What happens if after a few sprints the estimates are much higher than the initial estimates? Does the project sponsor lose all control over the budget in Scrum projects? The opposite is actually true. The project sponsor always has options due to the new, incoming information about the total budget. This is one of the main advantages of Scrum. Early on in the project, the project sponsor has functional software containing the most prioritized functions and offering the greatest benefit. In this case, the project sponsor has four options:1. If meeting all requirements is expected to cost more than budgeted, the project sponsor can abort the project at an early stage. A basic version of the project is generally released after just a few iterations.
2. The project sponsor can let the project run until the planned budget is consumed and then suspend or terminate the project. In any case, they will have functional software that contains the most important functions.
3. The project sponsor has the option of changing the project scope by postponing or omitting less important functions.
4. The project sponsor can increase the budget.
Scrum allows the project sponsor full budget control and thus full flexibility while reducing the risk of cost explosions because of big-bang implementations.
This article appeared first on ScrumAlliance.org