Budgeting in SCRUM by Divante
3 likes1,162 views
The document discusses budgeting approaches for SCRUM projects. It notes that budget overruns are common in both SCRUM and waterfall projects. For SCRUM projects, overruns occur at the sprint level and are easier to control. The document provides several budgeting approaches for SCRUM projects, including estimating costs, completing initial sprints before full budgeting, and deploying an MVP after 50-75% of the estimated time. It also discusses using planning poker and measuring team velocity to help with estimates.
Budgeting in SCRUM by Divante
- 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