Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Getting RID of Risk with Agile

Getting RID of Risk with Agile

Have you ever had to work on a project with poorly defined scope or requirements? How about projects that already had a large amount of technical debt, or technologies that you haven’t previously used? How about dealing with dependencies across teams, platforms, time zones or even all of the above? As an Agile coach I come across all of these sort of these challenges on a very regular basis. The reality of modern software development is that these are every day challenges that we have to deal with, and the skill lies in reducing these risks in a timely enough fashion that we can still deliver the most value to a users in a timely, sustainable fashion. How I hear you ask dear reader, how can we possibly achieve that? I don’t have a silver bullet, but what I do have is a system that can help us deal with risk in a more timely manner.

Risk and Agile

For Agile planning and estimation (and for any type of project for that matter) there are multiple types of risk that we have to be able to understand to be able to accurately plan our work, and to be able to deliver that work in a reasonable period of time. The most common types of risk I observe in any given piece of work can typically be distilled down to the following factors:

Requirement risk: For example, poorly defined stories, large scope of work/size of story (often numerous acceptance criteria for any given user story), or lack of understanding of customer value/prioritisation

Implementation risk: For example, working with new or unknown technologies, dealing with legacy codebases, lack of process/testing automation, or other technical debt

Dependency risk: For example, any cross team/product/platform dependencies, working across (multiple) timezones, or any external dependencies such as clients, partners or outsourced development

Well great you say, now we have some common patterns of risk, but what can we do with that information? It’s all very well understanding risk, but if we don’t identify that risk early and then put in place some sort of mitigation plan, then we’ll end up in the same old position that we are currently in. The next step we need to put in place is some method that helps identify risk earlier in the process: release planning.

Release Planning


(Click on the image to enlarge it)

RELEASE PLANNING GRAPHIC - Reproduced with permission from © 2011-2014 Scaled Agile, Inc. All rights reserved.

The concept of planning multiple iterations isn’t rocket science. The Scaled Agile Framework has laid out a great visual system for understanding the work targeted (but not committed) for multiple iterations, and does a good job of highlighting higher level risks to our work. The output of this iteration mapping is a rough plan for the next 5 iterations worth of work, mapping stories into iterations based on previous velocity and team capacity, giving us a great idea of the coming iterations output and stories we’ll likely pick up.

Requirement Implementation Dependency (RID) Risk

During this iteration mapping process we can work through the stories we’ve targeted (starting, logically with those coming soonest), and identify risk levels for Risk, Implementation and Dependencies (RID), simply stating whether for any given story we are facing HIGH, MEDIUM or LOW risk. This has two impacts: firstly it has some impact on estimation in that riskier stories will naturally be estimated at a larger size (high risk reduces output); and secondly, having understood risk levels, we can work to reduce risk.


At a release level we can do a number of things depending on the type of risk identified - Requirements, Implementation or Dependency:

For Requirement risk we could potentially break down the story into multiple pieces and ensuring work is well prioritised, something that should constantly be refined throughout the process (for example using the MoSCoW system, story mapping, or buy a feature prioritisation), and work to ensure the user stories we are working through are well defined user stories - do they discuss who we are delivering value to, what value we are delivering and why we want to deliver that value? Do they meet the INVEST model for good user stories? Working through these issues will help negate requirement risk.

For Implementation risk we need to understand the issues at play: Are we dealing with a large amount of technical debt, and if so, are we going to work towards reducing that debt before moving onto other work (in which case technical debt stories may move further up our backlog). For new technologies, do we need to introduce a spike story to understand and make the best decisions about how to progress (in which case we may add the spike stories and push back stories with high implementation risk until the risk is reduced).

For Dependency risk we need to understand the type and cause of the dependency. Is it possible to split the work in another way in order to reduce the dependency risk? Is it possible to enable the teams that have dependencies to collaborate more efficiently - for example setting aside specific times for the teams to collaborate? Do we need to push one story further back so that its predecessor can be committed to and completed before we begin work? If we are waiting on partners or clients, how can we make sure we have what we need in a timely fashion? The earlier we raise these potential roadblocks that more likely we are to come to a satisfactory resolution. We need to make sure we are collaborating with partners and clients as effectively as possible.

By identifying all of these risks during release planning, giving us more of a long term view, we can adjust our plans and introduce ideas to reduce risk. However the nature of our work isn’t static, and requirements naturally change and evolve over time. Working at these plans at release level is one part of the equation, but we need to be looking at risk on a more regular basis than this. Iteration planning is simply too late because by that stage we really are committing to work (and have no time to reduce risk), so enter the backlog grooming meeting.

Backlog Grooming

There are several common problems I come across with Agile teams during the iteration planning phase:

  • Poorly defined stories (especially acceptance criteria)
  • Stories with too many or complex dependencies
  • Oversized stories
  • ‘Ramp up’ stories (for new technologies or new team members)
  • Overcommitted teams (due to a number of factors)
  • Poor understanding of the work to be done

It isn’t possible to pinpoint just one factor behind these problems, but by examining work to be done before the planning it is possible to help face some, if not all, of these issues. Backlog Grooming is a chance to examine that work, and to reduce these issues.

Backlog Grooming, for teams that do it, is a session that happens somewhere around the midpoint of a iteration. The idea is to give the team some foresight into the work that is approaching, and to make sure it is ready to be accepted into our iteration backlog. How do we know when work is ready? When our definition of ready is satisfied. So in this session we examine each story, at a relatively fine level of granularity, to ensure that our RID risk factors are low (or at a stretch, medium) risk.

The process I follow works something like this:

  1. Product owner presents roughly prioritised backlog to the team (around one and a half iterations worth of work based on gut feeling seems to be the sweet spot)
  2. Starting from top priority story, rank the RID risk as high, medium and low.
  3. For any high risk stories identify cause of the risk, and then work to reduce risk (as per the description above). For stories when risk can’t be reduced either introduce an action item to be carried out before start of next iteration or reprioritise
  4. Continue until all stories meet DoR (if they are likely to be included in next sprint)
  5. Size stories as a gut check (if stories are too large, there is likely some risk that hasn’t been factored)


If we follow this type of workflow by the time we get to iteration planning the team not only has a great idea of the work coming up to be done, but it is also in an ideal state for us to begin working on. It helps the product owner be a lot more certain about their prioritisation, and means they can more effectively communicate any issues that they have with their stakeholders, users etc. Following this workflow also greatly increases the fidelity of our planning and helps teams feel a lot more confident in reaching their iteration commitments. A great win from a simple session.

Next Steps

Hopefully by now you can see the value of assessing risk for the work you are taking on. While RID may not be the right fit for every team (you should understand the risk you are facing a lot better than I do), having a process in place to ensure you are only accepting high quality, well defined work into your backlog helps us to achieve a lot more reliable, repeatable process.

From the teams perspective high quality work means they can have more confidence in reaching their iteration commitments and less frustration from dealing with poor quality work. From the Product Owners perspective they will find a lot more confidence in the plans that they co-create with their teams, have more understanding of what risks the team is facing, and much greater confidence in long term planning that is required for working with the business and other stakeholders. Most of all having a shared understanding between the team and product owner is essential to developing a high performing team.

We spend a large amount of time thinking about how to support the development team and ensuring they can develop high quality work, but not nearly enough time thinking about how to support the product owner and ensuring only high quality, high value work is reaching the team. This is a step in the right direction, why not take it today?

About the Author

Jacob Creech is an Agile coach and trainer, based in Shanghai, China, where he is the co-founder of Boost Agile, an Agile training and Coaching organization the supports organizations across Asia-Pacific. He is also the founder of the Shanghai Agile & Lean Startup user group. As a lifehacking fanatic he is always searching for (and creating) faster and more efficient ways of working, and he is an advocate of Agile across all aspects of life, having written about and applied Agile to topics as diverse as Table Tennis and Photography.

Rate this Article