Your monthly dose of insightful Project Management articles

Your monthly dose of Project Management articles.

Risk Mitigation in Scrum

White Paper

© 2003-2019 Gunther Verheyen – Ullizee-Inc, All Rights Reserved

(adapted from “Scrum - a Pocket Guide”)

What better risk mitigation strategy than the frequent inspection of tangible, observable work results? What better base for informed management decisions than reviewable versions of product? The time-boxing of Scrum makes us perform such observations regularly allowing us strategic decisions regularly. We prevent risks from materializing rather than managing them.


Scrum establishes an iterative-incremental continuum. This sheds not only a different light on how work is performed, but also on how risk is perceived, and tackled.

In Scrum all work is organized in time-boxed Sprints. Sprints are slices of time with a fixed start and a fixed end date. There are many advantages to the technique of time-boxing. A Sprint is a container that shields its inhabitants from external distractions. It maximizes focus on getting enough work completed. The time management technique of time-boxing bounds focus with regular reflections so lessons learned can be incorporated from one Sprint to the next. It helps establish a situation of more continuous flow across Sprints, while keeping open the opportunity to absorb more disruptive changes in-between Sprints, or willingly and radically change course towards new or more value in a next Sprint.

The tangible objective of Scrum is to create valuable, working versions of product (called Increments) no later than by the end of a Sprint. All development work is reorganized to optimize our ability to respond to and capitalize on business opportunities.

‘Value’ is the answer to user, market and business demands and the overall measure of progress and success. Value is an internal assumption until a product version is actually released to the marketplace. Releasing to the marketplace regularly is the only way to capture and adapt to feedback and signs of appreciation, or lack there-off, of the marketplace. Value is optimized across Sprints. Although value cycles might exist that span several Sprints, this does not lower the ambition of creating Done Increments no later than by the end of a Sprint. Technical risk, i.e. risks related to the actual implementation, is controlled by producing working Increments within a Sprint (not: across) based upon defined and agreed development and quality standards.


Bear in mind that, certainly in an IT context, risk is typically defined as something technical (Will the system perform? Is the system scalable?). It covers the aspect of a product being technically solid enough to be usable (Will it hold? Not break?). But a mere technical or development perspective on risk ignores the fact that the ultimate goal of Agile development is to provide greater satisfaction with end-users and customers, to ensure that the products are useful. A product being usable is just the beginning. Agile should enable us to focus primarily on the business aspects of ‘Risk.’

Any proper development process should address the risk of not being able to capitalize on unforeseen and previously unknown market opportunities, of not releasing product fast enough, of being subject to customer dissatisfaction, e.g. by releasing untested versions, the risk of releasing functions that are not what users expect or appreciate, the risk of lagging behind with regards to the competition.

Development in Scrum is best organized in a way that maximally mitigates that business risk. High-value needs are answered first. Product versions and updates are released quickly and frequently. They satisfy existing needs as well as include unexpected, innovative functions. They get users to pay for the product and optimize the stakeholders’ return. They are of high quality in order to minimize maintenance and support and optimize the Total Cost of Ownership (‘TCO’).

Scrum does not ignore the value of the regular IT activities (in the figure coarsely represented as “Analyze”, “Design", “Code” and “Test/Integrate"). But Scrum requires breaking up their sequential organization to a more dynamic approach against the ambition to realize benefits fast, and frequently. To produce releasable versions of product, no later than by the end of a Sprint, the work activities are structurally reorganized into concurrent development. The different types of typical activities are executed concurrently with daily replanning and re-alignment via the Daily Scrum. The goal is to enable flexibility and speed instead of blocking them. All disciplines are performed in a non-linear, incremental way, concurrently and on a daily basis, by cross-skilled teams with continuous collaboration and negotiation about emergent ideas, techniques and practices.

The goal of such an integrated, cross-functional approach is to build-in quality and to prevent defects, rather than attempt to establish quality by a bug hunting approach in a post-creation phase. It is imperative to turn the desire to release regularly into the actual ability of doing so, and firm up your ability to go to market, often and reliably. Quality cannot be added to a finished product. Delays and budgets grow well out of hand when a lack of quality is identified once the actual creation process is over.

It might take some time to experience the fact that the continuous learning from actual work results, innate in Scrum, actually increases control amidst turbulent enterprise, business and market circumstances. It is certainly a lot more effective than academic risk mitigation strategies and managed risk lists, that offer no more than an illusion of control.

It might take some time to shift the focus of management away from a predicted approach to risks and a feeling of security via judgments of the past, e.g. via actuals and time registrations. It might take some time to gain confidence from optimizing and releasing business value through valuable outcomes of time-boxed Sprints. It does take experiencing Scrum rather than considering Scrum or breaking Scrum to fit old structures.

(Note: this article was adapted from the chapter “1.4 the iterative-incremental continuum” from the 2nd edition of my book “Scrum - A Pocket Guide”).


Exclusive 💬

Gunther Verheyen

About author

independent Scrum Caretaker

Gunther Verheyen is a longtime Scrum practitioner. After a standing career as a consultant, he became partner to Ken Schwaber (Scrum co-creator) and Director of the Professional series at Gunther nowadays engages with people and organizations as an independent Scrum Caretaker.

Gunther ventured into IT and software development after graduating in 1992. His Agile journey started with eXtreme Programming and Scrum in 2003. Years of dedication and employing Scrum in diverse circumstances followed. As from 2010 Gunther became the inspiring force behind some large-scale enterprise transformations. In 2011 he became a Professional Scrum Trainer.

Gunther left consulting in 2013 to found Ullizee-Inc and partner exclusively with Ken Schwaber, co-creator of Scrum. He represented Ken and in Europe, shepherded the ‘Professional Scrum’ series and guided’s global network of Professional Scrum Trainers. Gunther is co-creator to Agility Path, EBMgtTM (Evidence-Based Managing of Software) and the Nexus framework for Scaled Professional Scrum.

Since 2016 Gunther continues his journey as an independent Scrum Caretaker; a connector, writer, speaker, humanizer. His services build on 15+ years of experience, ideas, beliefs and observations of Scrum. Gunther helps people re-imagine their Scrum to re-emerge their organization and firm up their agility.

Gunther created the acclaimed book “Scrum – A Pocket Guide” in 2013 and published a 2nd edition in 2019. Ken Schwaber recommends it as ‘the best description of Scrum available’ and ‘extraordinarily competent’. In 2016 the Dutch translation was published as “Scrum Wegwijzer” and in 2017 the German translation as “Scrum Taschenbuch”. More translations are forecasted.

When not travelling for Scrum and humanizing the workplace, Gunther lives and works in Antwerp (Belgium). More at



Gunther is the author of the acclaimed book “Scrum – A Pocket Guide” (2013), which was recommended by Ken Schwaber as “the best description of Scrum currently available". A second edition was published in 2019 and a third edition is planned for 2021.


 Gunther Verheyen Book
Gunther Verheyen Book
View all articles