SCRUM projects budgeting

1. www.divante.co
Budgeting in
SCRUM
Tomasz Karwatka / tkarwatka@divante.co

2. www.divante.co
The work model currently employed by IT companies is mainly SCRUM with Time &
Material accounting for performed work. In such case, budgeting can be difficult. In
the waterfall model of software development, which was popular a few years ago,
such a problem didn’t occur. That model mostly employed Fixed-Price settlement
for individual stages or at the end of a project.
We’ve prepared a set of guidelines that can be helpful in budgeting SCRUM
projects.
Budget overruns are always possible
Work on IT systems is often research and development. Usually, it is difficult to
predict in advance all the nuances and problems. Budget overruns are just as often
- regardless of the model of project implementation.
In SCRUM projects overruns occur on the level of individual sprints and are easy
to control. In Fixed-Price projects, an overrun is usually detected at the very end
of a project, causing much more serious consequences. Overruns in Fixed-Price
projects are usually compensated with: a reduction in quality, prolonged execution
time, negotiations on the number of implemented functions or having to pay more
for the project.
Also, a mechanism of spotting and pricing changes is commenced, which is very
time-consuming for teams on both sides (devoting a lot of energy on searching for
deviations from specifications).

3. 2
www.divante.co
Planning
Divante’s Clients budget their SCRUM projects in various ways. Budgeting P&L
requires determining project costs in advance. Applicable approaches include:
1. Preceding cost estimation (and therefore budgeting) with a consulting
phase - analysis and design. Thus, the description of requirements is
more precise and allows for more efficient estimation with less uncertainty.
2. Creating an estimation in the „from-to” form or an estimation with a percentage
of uncertainty (if more than one person on the team makes an estimation, you can
measure the differences between them). Then, the higher estimate is put in the
budget and the potential savings are used in product development.
3. Adoption of cost estimation provided by an implementing company
and adjusting the scope of functions to the implementation on the
go - by priority and in accordance with triangle time-scope-cost-quality.
It’s the most common approach. If you adhere to the triangle and
Tim
e
C
ost
Scope
Quality
............................................................
........................................................
..................

4. 3
www.divante.co
communicate on a regular basis (e.g. presenting a demo after each
sprint), your client is not taken by surprise at the end of a project.
4. Carrying out an internal project estimation by a client’s IT department
and adopting this (usually higher) amount as the cost of a project. Such
estimation may also be made by an external consultant. In fact, implementing
a project in SCRUM allows you to change a contractor during the project.
5. Completing a few sprints before budgeting – to verify the assumptions for
the most difficult parts of a project and to determine the velocity of the team.
Example: When working for Grene, we first completed the sprints responsible for
the riskiest part of the project - data migration from existing solutions to Magento.
After that, we verified the estimates and launched the main project.
6. Deploying an MVP after 50% -75% of project time elapsed. In this case, backlog
is created in such a way that after elapsing 50-75% of project time, an MVP
(Minimum Viable Product) version is deployed and the remaining time is spent
on further improvements and functional expansion. This increases the certainty of
deploying the most important functions of the system in time and within budget.
7. Ultimately, P&L planning should be based on determining the amount of
resources dedicated to a project. Software is developed by assigning functions to
be implemented in sprints. Thus, in budgeting we assume software development,
but we don’t determine what features it will include. However, you can determine
what business goals are to be met in the software development.
You can also make the granting of additional budget dependent on results
obtained in previous sprints.

5. 4
www.divante.co
Risks in SCRUM
Convincing your CFO to use SCRUM can be quite difficult if the method is presented
as work without limited budget and vague scope. It is worth noting though that
CFOs and managers are heavily focused on identifying and minimizing risks. They
often prepare „what if” scenarios. SCRUM gives you a huge advantage over other
methods of work in the process of risk management.
There could be several reasons why the project has to be completed before the
planned date:
• Budget cuts
• Change in the priorities of the company
• Acquisition or other events halting development projects
• Established budget is not sufficient to realize the scope, which was widened
during the project.
What if the project has to be halted after 60% of its duration?
To demonstrate this below is a comparison of two projects. Project W is conducted
in the waterfall approach. Project S is carried out in SCRUM model.
Project W consists of the following stages:
• 10% of the time/effort - collecting requirements and scope
• 25% of the time/effort - analysis and design
• 40% of the time/effort - development and testing
• 20% of the time/effort - fixes, acceptance
• 5% of the time/effort - deployment
If you stop such a project after 60% it turns out that the team is in the process of
writing code and the business value of what we get is zero. The system simply
doesn’t work and the only finished product is a documentation.

6. 5
www.divante.co
In the case of Project S conducted in SCRUM the situation looks differently:
• 10% of the time/effort - collecting requirements and scope
• 85% of the time/effort - analysis, design, development, testing and deploying
next versions of the product in cycles of 2-week sprints
• 5% of the time/effort – closing the project
After 60% of the time in the SCRUM project we have a working system with the list
of features realized in 40-50%. The system has real business value.
A chart showing business value delivered in both models:

7. 6
www.divante.co
Implementation of SCRUM project provides a linear increase in business value,
including project costs. It’s safer to implement from the perspective of risk
management.
Source: www.scrumalliance.org
SCRUM estimates
The first step is to set the quality of collected requirements. The team shares their
experience and creates a list of questions to the collected requirements.
Then, each of the requirements is assigned to one of the groups:
a) The requirement is clear, we don’t anticipate significant changes,
b) The requirement is incomplete, we anticipate moderate changes,
c) The requirement is ambiguous, we anticipate many changes,
d) The requirement is not specified, there are no specific requirements.
Next, we create a summary table:
Requirement Type Percentage
20%
30%
35%
15%

8. 7
www.divante.co
In the first table almost 50% of the requirements is assessed as clear or requiring
moderate changes. In the second table up to 70% of the requirements are not
clear.
To minimize risk, you can use the following approach:
• Introduce a separate analysis and design a phase to move all the requirements
from the „ ambiguous” to „clear” and „moderate changes anticipated”.
• Risks associated with unclear requirements are determined and estimates for
them increased several times.
• High priority ambiguous requirements are implemented first so that potential
overruns in these areas leave room for maneuver in choosing functions in the
following sprints.
Below we describe two tools used in managing SCRUM projects, useful in making
estimates.
Requirement Type Percentage
10%
20%
40%
30%

9. 8
www.divante.co
Planning Poker
Estimates as to the size of a SCRUM project are often made using Planning Poker.
The method is based on compromise and assumes that each team member
participates in making estimations for each task from the list of functions (backlog).
The session begins with handing each participant a deck of cards, each card
contains one estimate. Each person who estimates should have a deck of cards
with values of 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
A session moderator reads each user story that the team has to estimate. After
reading the description of a user story, the product owner answers all the questions
that have arisen from the team.
After a while, every team member makes a subjective evaluation of the user story,
the card’s value is not disclosed until all members of the session make their choice.
Then, the cards are reversed simultaneously and the whole team sees the estimates.
There is a high probability that there will be significant difference in the estimates,
it’s not a bad thing. In such a situation, the person who gave the highest and lowest
value explain their motives for such assessment.
The next step is to repeat the vote, again the cards are reversed and the whole
team votes. Usually in the second round the team determines a final estimate.

10. 9
www.divante.co
Team velocity
In SCRUM, velocity means the same as what piece of backlog product the team is
capable of doing in one iteration (sprint).
We can calculate estimated velocity value based on recorded statistics of previous
sprints, assuming the team has the same members and the sprint has the same
duration. Knowing team velocity is not a small thing when it comes to sprint
planning, based on the value, a product owner knows how much the team is
potentially capable of doing and how it can plan the next iteration.
The stable value can be used in planning a road map, as it provides forecast of a
live deployment of a given release. However, we can’t simply transfer the velocity
of one team to the other, even while maintaining the number of people and
duration of the sprint. Undoubtedly, the metric will vary for different projects, e.g.
the velocity of a 5-person team may be better than the velocity of a 7-person team
and vice versa. Even if the productivity of their members is similar, we will never
manage to reach the same velocity value for both teams, it’s not about that.
Velocity should be measured carefully from iteration to iteration, with the stable
value we can have a relatively stable release plan and we can anticipate and
forecast future releases. Many businesses want to inform their clients in advance
about a planned product road map they have and tell them about the planned
functions. This is important for the perception of the company externally as a good
partner who has a solid background and well-arranged internal processes. This is
also important within the company because a stable velocity value can accurately
support resource plans, budget and the planned scope of a project.
Both descriptions: www.mountaingoatsoftware.com

11. 10
www.divante.co
Contact
Let’s talk about the best methods to help you optimize your eCommerce.
Tomasz Karwatka
CEO
tkarwatka@divante.co
Ernest Trochimczuk
CSO
etrochimczuk@divante.co
Marta Miszczak
Sales Manager
mmiszczak@divante.co
Krzysztof Podeszwa
Sales Manager
kpodeszwa@divante.co

12. 11
www.divante.co
Divante LTD
14 Kosciuszki Street
50-038 Wroclaw, Poland
sales@divante.co
(+48) 797 340 458
www.divante.co