Two Sides of the Same Coin: Risk Management and ROI in Scrum

Return to Newsroom

By Katie Playfair

Every day I talk to customers who are using Scrum, and every once in a while I hear from a team on which every member is completely convinced of Scrum’s merits. Those teams are not the norm. Most teams and even individuals have some healthy skepticism about an approach so different than the traditional paradigms they’ve worked in for years.

The most common concerns I encounter are about ensuring strong risk mitigation and improving ROI. Although the metrics used to communicate risk mitigation and ROI are different, the reality is that--despite it being a lightweight framework--Scrum puts a much greater emphasis on these two areas than waterfall. (Because my discussion will focus on how Scrum reduces risk and increases ROI, I will not discuss which metrics are most valuable in Scrum. However, I would recommend interested parties consult Dan Rawsthorne’s article on EVM and EVB, which can be found here.)

But before we get any farther, it bears repeating that Scrum is really pretty simple. It’s a framework that asks teams to self-organize, develop iteratively and deliver incrementally. It employs empirical processes to inspect progress and nimbly respond to emerging business conditions. There are three roles, four meetings and three artifacts (for more information on Scrum’s roles, meetings, and artifacts, head here). It tends to value being a lightweight framework designed for flexibility and adaptation without abandoning security and structure. No wonder, then, that managers break into a sweat when they consider applying Scrum to a mammoth, multi-million dollar project.

So if we’re not going to conduct a detailed up-front risk analysis and develop an exhaustive plan full of contingency management, how we do handle major risks with Scrum? In my experience and in that of Certified Scrum Trainer Michael James, technological risk, cost/delivery time, faulty requirements and human capital (we like to call them “people”) are the most common risk concerns. Scrum addresses each of these in a manner different than traditional project management paradigms.

In terms of technological risk, Scrum advocates a “fail fast” philosophy (for insight into this rationale from an engineering standpoint consult Kane Mar’s white paper on technical debt). The benefits of this approach are clear from the business perspective. Namely, would you rather discover architectural or integration problems after spending one month and $30,000 on a project, or after spending three years and $1.08 million? Scrum’s directive to produce a potentially shippable increment of software each sprint forces teams to confront technological impediments from the beginning of the project.

By asking a team to immediately develop working software, they “run into” technical impediments that, if discovered late in a traditional development cycle, could throw months of analysis, architecture and coding out the window. Rather than developing software in a vacuum, Scrum actively mitigates risk through the repeatable work cadence of the sprint. The sprint review meeting (which concludes every sprint) acts as a kind of “reality check” for the product owner, who can make an informed assessment of the project.

To reduce risk associated with cost and delivery time, Scrum asks product owners to re-evaluate the business value of each story before prioritizing it. In order to do this, the product owner solicits effort estimates from the team for each story and then prioritizes the estimated stories in the backlog. To determine what will be built next, the order is based on the business value they will yield and their “cost” (team effort) to build. Since value and technical difficulty are negotiated regularly, the product owner can help drive the team toward the organization’s goal, often a moving target. Often this goal is a critical mass of features by a specific date, or an estimate of 100 percent product completion by a flexible date.

Another important organizational risk is clarity of requirements and scope creep during the clarification process. New product development almost always entails incomplete, poorly defined or evolving requirements. Quite simply, there are very few individuals who can articulate a vision for a product in absolute terms. And there are even fewer teams who could interpret them so perfectly that the final product reflects that vision. I know I’m guilty of “I’ll know it when I see it” (IKIWISI). Luckily, the Scrum process brings the product owner and team together to discuss progress and collaborate/recalibrate its direction throughout the development lifecycle. With regular opportunities to guide the project toward success, Scrum renders the notion of “faulty requirements” obsolete. (If a Scrum team is legitimately hampered by faulty requirements, it may reveal a larger organizational problem, in which product owners are unclear about what the business needs.)

Finally, Scrum manages the risk associated with human capital by distributing responsibility to the appropriate individuals. Let me explain: How many times has a non-technical project manager made decisions on technical feasibility issues without consulting the development team, who actually understands the magnitude of the problem? That sort of uninformed commitment is akin to a developer independently deciding how a field in an accounting system relates to the general ledger--even though she can’t balance her own checkbook.

To avoid this, Scrum separates its roles into collaborative expertise domains: The product owner acts as the business expert, the team acts as technical experts and the ScrumMaster helps facilitate the process, acting as a servant-leader by telling the organization what the team needs to be more successful. Of course, Scrum also regiments the conversations between these individuals and groups to make sure that business, technical and process inputs are included in every story. Interestingly, when teams are given more responsibility, they often find their jobs more rewarding.

According to Pat Elwer of Intel’s product development engineering (PDE) division, “Job satisfaction comes from consistently hitting goals established with velocity-based planning. The team feels incredible pride in its ability to make and meet commitments. Morale is much higher and the sustainable pace is greatly valued in the organization.”

Because the Scrum framework is adaptive rather than prescriptive, there are ongoing opportunities throughout the development lifecycle to steer a project away from risk--and toward ROI. However, many increases in ROI are indirect and therefore difficult to measure or track, so I’ll only point out a few ways in which Scrum bolsters ROI. For example, blunders that cost millions of dollars can be avoided using the risk management techniques outlined above.

Technological risk is evaluated through the team’s actual development of functioning software and, if the risk outweighs potential business value, this conclusion informs critical decision making. Highest priority backlog items should be delivered in full, ensuring that scope creep only affects items that are truly valuable and worth developing. Changing requirements are welcomed as a means of delivering items containing the highest business value first.

Finally, team members, product owners and ScrumMasters are entrusted with authority in their respective areas of expertise, yielding creative freedom, job satisfaction and employee retention savings. Many of my clients estimate that it takes 300 percent of an employee’s annual salary to replace them, and studies back up that claim--even for low-level employees.

As you can see, the engine that drives ROI in Scrum is its comprehensive emphasis on risk management. By building constant communication and collaboration into its processes, it systematizes risk detection and resolution as ongoing activities. And such a rigorous attention to preventing risk works hand-in-hand with generating greater ROI. So for those Scrum professionals wondering if Scrum adequately addresses risk management, maybe change isn’t so scary after all.

Katie Playfair is a Certified Scrum Master and Director of Client Services at Danube Technologies, Inc. She helps guide the activities of Danube’s ScrumCORE team, comprised of five Certified Scrum Trainers, several partners and client service representatives.

This article originally appeared in the online edition of Gantthead on Monday, October 6, 2008. To access it online, visit:

Risk_Management_and_ROI_in_Scrum_Gantthead1008.pdf136.52 KB