Using risk to prioritise software development projects

Risk can play an effective role in ensuring that user stories are prioritised to bring real value to sprint planning.

For Agile and Lean-Agile teams, prioritising user stories often come from using various techniques across software teams, product owners, and stakeholders. And while things like effort and business value come up frequently in planning, “risk” often doesn’t get a look-in when it comes to less experienced teams working on a project.

But what do we mean by risk, and how does it affect user stories and features? Read on to find out.

The four factors of prioritisation

In his book, Agile Estimating and Planning, Mike Cohn describes four “factors” to consider during planning. Cohn suggests grouping user stories and features into “themes” and then aligning these themes against the four factors. These factors are:

1. The financial value of having the features.

2. The cost of developing (and perhaps supporting) the new features.

3. The amount and significance of learning and new knowledge created by developing the features.

4. The amount of risk removed by developing features.

Source: Agile Estimating and Planning by Mike Cohn, p. 80.

Often value and cost get the most significant consideration, but learning and risk are also important.

And as we’ve repeatedly pointed out across our blog, when it comes to developing in an Agile or Lean-Agile way, gaining new knowledge over the course of a project is vital. It helps teams become more efficient and effective and gain knowledge and skills that can be used on future projects.

But what about risk?

Types of risk

Risk in this context is anything that can threaten project success. Cohn says you can divide software project risks into two broad categories:

Business and technical.

Business

On the business side, you’ll find such risks as:

• Schedule risk. Here, several things can contribute to putting a project behind schedule, including:
  • Scope expansion where stakeholders unexpectedly push for more features.
  • Poor time estimation for story completion.
  • Resources like team member availability, skills, and so on are poorly tracked.
• Budget risk. Again, a host of things can jeopardise spend overrunning if cost is a concern. Causes here can include:
  • Scope expansion (again).
  • Poor work prioritisation, so sprints aren’t delivering business value.
  • Unworkable cost estimations.
• Operational risk. The day-to-day running of a project can bring up a host of issues. Problems here can include:
  • Poor psychological safety among team members causing conflict and poor communication. Especially if team members feel unable to voice safety concerns they have about the product.
  • Little to no clarity of people’s roles and responsibilities.
  • Not enough skilled team members to carry out the expected workload efficiently.
• Pragmatic risk. These are unavoidable risks outside the organisation that can impact a project. Problems here can include:
  • Changes in government regulations regarding products in development. (A good example would be the recent changes to MDR and IVDR affecting medtech in the EU.)
  • Sudden shifts in the marketplace, making products irrelevant or needing to pivot.
  • Supply chain issues affecting parts (the chip shortage has been a challenge for embedded systems manufacturers).

Technical

And on the technical side? Technical risks are incredibly varied and impacted by the technologies and languages used in a project.

General ones can include:

• Poor documentation creation and maintenance, making onboarding new team members difficult or causing knowledge gaps when team members leave. It also creates operational risk for compliance-heavy projects.
• Functionality issues such as teams being unable to get a feature to work.
• Infrastructure issues, like security needs, and when to address them. Too early and security can hold up a project. Too late, and it might not be possible to secure a product to the level needed.
• Usability testing left too late leaves a project open to risks around usability and checking whether the team is building the right thing from a user’s perspective.
• Having high complexity where a project has a lot of different subsystems involved.
• A build-up of technical debt because software and architecture are not being made maintainable. Doing this leaves products with poor conceptual integrity making support and adding future features hard to do.
• Requirements changing too often and not being kept up to date, causing the wrong stories to be developed or tested.
• Poor coding practices, such as not doing test-driven development, relevant testing, or code reviews. This can lead to an increase in defects and unhabitable code that is more complex to write and harder to understand and maintain.

Both business and technical risks need attention during story prioritisation, but risk alone is not enough to go on.

Risk as a risk-value relationship

As said earlier, the risk can’t be the only driving force around prioritisation. One of the best ways to get a handle on it is by looking at the risk of features alongside their business value.

Cohn proposes that we look at this “risk-value relationship” to help us understand what order to work.

Features can sit in one of four quadrants, like so:

By aligning between:

• High risk and low value
• High risk and high value
• Low risk and low value
• Low risk and high value

It’s possible to start seeing what order you should prioritise. Activities that lead to high-risk and high-value features should be worked on first. In contrast, high-risk and low-value features should be avoided as much as possible.

Aligning features to risk in the above way means ordering features as so:

Ultimately, you’re looking to get the right balance between risk and business value—meanwhile, considerations around development cost and what teams might learn need care too.

Risk and value aren’t the only factors

Obviously, considering prioritisation from one angle will not be enough to get the most out of project sprints. You don’t necessarily need the whole team and stakeholders to be the ones ordering work. As Cohn points out, the product owner can often be the one to help shift priorities and communicate this.

Cohn explains that prioritisation should work in this order:

1. Look at the value of developing a feature versus what it would cost to develop.
2. Look at the total value of a theme once all its features and user stories have been evaluated.
3. Compare these theme values based on risk—what is the risk of leaving something to later? If it’s essential to have a technology early, it shifts a theme to earlier in a project.
4. Frequent reflection by the dev team, stakeholders, and product owner can help check if priorities are still in the best order.

Source: Agile Estimating and Planning by Mike Cohn, p. 86.

Three ways to keep risk in check

So, what can you do to keep project risk in check? The following list isn’t exhaustive, there are other practices you could use to try and keep project risks in check (like scoring and tracking risks), but these can be super helpful.

Regular sprint reviews

Now you are tracking the risks, review them regularly. A sprint is a set period, usually between two weeks to a month, where a software team works on user stories in a backlog. A sprint review enables teams to show stakeholders and product owners what’s been developed over the course of a sprint. A team can explain challenges that have crept up in delivering user stories. Stakeholders and product owners can look to change project priorities based on this information. New risks might have arisen or been mitigated.

UX-led usability testing

UX focuses on users and their needs and how they align with business value regarding product features. Through practices like usability testing, it’s possible to check that the features developed in a sprint are ones users can and will use. You can check for friction where things don’t work as expected for users and improve uptake of them as well. Early usability testing reduces the risk of building the wrong thing. Itcan be incredibly critical in sectors with standards around usability, like IEC 62366 for medical devices.

Value stream mapping

Running a value stream mapping session between software teams, product owners, and stakeholders can help uncover time sinks that are causing scheduling risks. If time estimates have been very inaccurate recently, all parties can work together to map out how long various tasks take to complete (value time) and the time between tasks where nothing happens (waste time). Should there be long stretches where nothing is happening, for instance, then all parties can work together to find a way to end having so much wasted time.

You can’t plan for all risks, but you can be ready for them

I hope you’ve found this blog post helpful. It’s not possible to identify all risks during project planning. Prioritisation can also change during a project. What is possible is making sure that everyone involved has the means to identify and evolve project work as new information becomes available.

Earlier I mentioned psychological safety as a potential risk. If you’d like to learn more about psychological safety and how it can impact software projects, download your copy of Why is psychological safety critical to managing software risk? today.

Why is psychological safety critical to managing software risk? will help you

• Understand the four stages of psychological safety.
• See how psychological safety impacts risk in teams and whole organisations.