Get certified - Transform your world of work today

Risk and Scrum

09/03/2013 by Matt Gilliland

Scrum and other Agile frameworks don't have an explicit method for highlighting and handling certain types of risks. Most Agile frameworks imply that risk will be handled by using a combination of the following techniques:

  • Relative estimation using modified Fibonacci scale -- this essentially gives all estimates a plus/minus 50 percent estimate range
  • Short iterations/increments/cycle time
  • Breaking work down into smaller items -- this reduces risk by reducing complexity
  • Research spikes -- if you are not sure about an approach, timebox a research task with the goal of determining how to move forward
  • Steel thread architecture -- complete a small end-to-end slice of functionality as soon as possible to prove the approach is effective
While these techniques reduce most common risks more effectively than Waterfall's identify-and-plan method, they do leave a few holes. For instance, risks around dependencies on other projects, features, stories, decisions, teams, etc., plus market risk, are difficult to account for.
Below is a brief outline of how I identify, track, and quantify risks like those above.
  • The project manager, product owner, ScrumMaster, or business analyst can all be responsible for facilitating risk identification (with the team's help), tracking, and management.
  • Regularly review as an agenda item in road mapping and release planning (for identification and sometimes quantification), sprint planning (for tracking and managing), and retrospectives (mitigating risk types through process change).
  • Documented in the project/team backlog as a risk-issue type. It should be lumped together with stories that may trigger or are closest to the forecasted risk timeline.
  • Issue type: Risk
  • Summary: Risk -- risk summary
  • Description: Risk description -- include triggering event/timeline
  • Probability: Percent probability
  • Impact: Impact in terms of estimated additional story points of work if the risk is triggered
  • Response: The possible response plans/actions (these describe the work that would be triggered if the risk is realized)
  • Story Points: Impact * Probability
  • Reduce unplanned and un-budgeted/allocated work on a release/project level.
  • Set more realistic expectations around work to be completed and reduce surprises to stakeholder groups/product owners.
Let's illustrate with a sample project. The project scope is to develop a new eCommerce Web app. For various reasons, the business would like to host the app internally.
The current infrastructure cannot accommodate the volume of traffic the site is forecasted to receive. Work is in progress on a separate infrastructure upgrade project and it is scheduled to be completed in time for the app deploy. This infrastructure project, though, has been plagued with delay and setbacks and there is a high chance it will not be complete in time for the new eCommerce Web app. This leaves two options: Delay the site launch or deploy to the cloud.
To accommodate the schedule risk of possibly needing to deploy to the cloud, we would create a story/risk and add it to the backlog, inserted around the time we are likely to know if the infrastructure upgrade will be completed on schedule
The risk-story might look like this:
  • Issue type: Risk
  • Summary: Risk -- Infrastructure might not accommodate high volume traffic by launch.
  • Description: The completion of the infrastructure upgrade project is required to enable the company to host the new Web app. This project is likely to not deliver the needed capacity or to deliver it substantially late.
  • Probability: 50%
  • Impact: Response A (250 SP), Response B (delay launch until infra upgrade done -- delay unknown)
  • Response:
    • A -- Tweak the app to enable cloud/external access back to preexisting, internally hosted sources of record.
    • B -- Wait for the infra upgrade project to be completed.
  • Story points: A – 175
This story would be included in status reporting to indicate how long the project may have left to completion.
Another example may be when it is appropriate to highlight technical risk that isn't solved by a research spike. For example, engineers may be fairly confident that a certain approach will work and start down that path, but then they find they are not able to complete an end-to-end story (perhaps due to component teams or other blockers). Therefore a certain amount of effort has been put in before finding out it won't work. This is a good time to use a risk story to provide that buffer instead of surprising the stakeholder group/product owner with a status report indicating that something might slip out of the release due to the extra work (or surprising the team with overtime requests).
I like to add an agenda point to release planning meetings (sprint planning also has worked) to spend a few minutes focusing on identifying risks. This also leads to good follow-up conversations in team retrospectives as we reflect on how our process can limit and/or help us identify risk systematically in the future.
To conclude, while Scrum handles most risk through the nature of the way in which work is accomplished, many teams and companies are working within imperfect Scrum implementations, so a few types of risk may still need extra attention. Perhaps the above method will spark some ideas of your own -- or at least remind you to not forget your risks!