SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Tomasz Karwatka / email@example.com
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
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.
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
• 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.
WANT TO GET THE FULL
Let’s talk about the best methods to help you optimize your eCommerce.