Agile Is a Risk Management Strategy

Some people claim that agile software development is a risk management strategy.


Because all principles of risk management are nicely covered when you've implemented an agile process.

The International Organization of Standardization has identified the following principles of risk management in their draft of ISO 31000 “Risk management — Guidelines on principles and implementation of risk management”:

  • "Risk management should create value."
    In agile projects (re-)assessment of business value, for prioritized user stories, is done in every sprint/iteration.
  • "Risk management should be an integral part of organizational processes."
    When you're doing agile, you're doing risk management, therefore it is part of the standard process.
  • "Risk management should be part of decision making."
    Every time you prioritize user stories, and every time you list impediments, you prioritize associated risks as well.
  • "Risk management should explicitly address uncertainty."
    Uncertainty has been one of the main drivers behind the whole agile software development movement.
  • "Risk management should be systematic and structured."
    A product backlog is systematic and structured. And the same applies to sticky notes with impediments on a task board.
  • "Risk management should be based on the best available information."
    Meetings involve the whole team, including the Scrum Master and Product Owner, to maximize available information.
  • "Risk management should be tailored."
    Retrospectives are meant to tailor the process on-the-fly, to match the environment and the project.
  • "Risk management should take into account human factors."
    That's why risk management is done with all stakeholders, and not single-handedly by a project manager.
  • "Risk management should be transparent and inclusive."
    The backlog includes all risks identified but not yet tackled. And the impediments on the task board are visible for all.
  • "Risk management should be dynamic, iterative and responsive to change."
    Iterative? Responding to change? Now where did I hear that before? It had to do with a Manifesto, or something…
  • Risk management should be capable of continual improvement and enhancement.
    Continuous improvement is what retrospectives are for, and it's at the root of everything that is agile.

You can see that all principles of risk management, as required by ISO, are covered by standard agile project management processes. Of course, it requires that risks are identified by both the customer and the team, and made visible on the backlog and the task board. This also fits well with my previous blog entry (Risk Management = Banana Peels AND Dollar Bills), where I wrote that risk management not only covers problems (impediments), but opportunities (user stories) as well.

Some examples of risk management could be:

  1. If we don't finish user story A before deadline T the CEO is going to kill someone, and we will have to buy the CIO some flowers when he's in hospital.
  2. We better assign user story B to this sprint, because Karl is the best developer to pick it up, and he will go on a 6-month vacation to Louisiana State Penitentiary next week.
  3. User story C will deliver lots of business value, but that value will only be earned when we release it immediately after the marketing department finds out about the dead parrot.
  4. The team must work hard to keep velocity at a high level, but there's a possibility some resources will be pulled away next week to fix the coffee machine in the executives wing.
  5. The customer has not been able to review our latest demos, despite our efforts to beam the demo on the walls of the office building across the road.


Every risk identified by the team and the customer is either a user story or an impediment. Risks are evaluated in every sprint meeting and every stand-up meeting, and the team, the Scrum Master and the Product Owner take appropriate measures to manage them.

That's why agile software development is a risk management strategy.

However, I have also good reasons to claim that agile software development is NOT a full risk management strategy. But that's a story for next week…

(images by hellosputnik and the fayj)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
People Don't Listen
Three Levels of Control
How to Handle Many Simultaneous Projects

  • Risk Management = Banana Peels AND Dollar Bills
  • This Post Is NOT About Michael Jackson
Related Posts
free book
“How to Change the World”
  • Cory Foy

    Must be the time to think about Risk, since I just did an article entitled “Hope is not a Risk Management Strategy” ( The key being that Frequent Releases, Frequent Communication, Strategic Vision and Exit Strategies are – all of which dovetail nicely with agile practices.
    I don’t think I’d call any specific methodology a “Rish Management Strategy” since risk management is a people thing, not a process thing. I’m looking forward to your next article on it.

  • Pradeep Bhanot

    While I would agree the elements of the ISO standard you refer to do coincide with elements of agile approaches, the context for the standard is much broader. Most importantly, the ISO definition of risk applies to developers of risk management policies and it deals with broad organisational and legislative issues at a macro level. An agile sprint is a pretty time boxed activity of perhaps two weeks for example, whereas risk management strategy is a continuous process with a long time horizon.
    Agile approaches are pretty introverted (other than including the customer), so is missing the inclusion of many external factors that a risk assessment would.

  • Jurgen Appelo

    Yes, I agree with that position, and I intend to write about it next week.

  • reboltutorial

    Deming, the father of Modern Quality Management didn’t like ISO because ISO are just slogans whereas he said in one of his 14 points on Management (see for example here ):
    Point 10: Eliminate the use of slogans, posters and exhortations for the work force, demanding zero defects and new levels of productivity without providing methods.

  • reputation management

    Very good article. I think we will try this in our team. we’re always looking in something new in agile practices.There’s only one question. Could you describe in more details the structure of this risk board please?

  • Jurgen Appelo

    I don’t have more information available right now. But one of the chapters in the book I’m writing will be about risk.

  • Anita

    Hi Jurgen, Is there a risk register/treatment plan template that you would recommend using in an Agile Project? Would you be able to please provide me with an example of a Software porject risk analysis and treatment plan done for a software project done in Agile? Thanks in advance.

  • Jurgen Appelo

    Sorry, I have no knowledge of such tools.

How to Change the World - free Workout - free