How Risks Can Be Used for Prioritisation
A story about a much-needed change of perspective.
Amongst other things, many testers are really good at critical thinking and risk identification. These skills are useful not only in testing, but also in project management. More specifically, prioritising.
This is the story of how I discovered an approach to using risks for prioritisation.
Running Out of Time
We had one year left. In twelve months we had to go live with our first customer. 52 weeks to prove that this service could actually make money. 365 more days of passionate work on the service we believed in.
If we failed to deliver on time, the project we had put so much hard work into would be over. Forever.
We looked at the backlog with all the epics, enablers, stories, tasks and their rough estimates and thought: All of this seems important and necessary for our service to be of value to our potential customers.
How can we possibly reduce the release scope?
The Epic Table
So we got together to find an answer to that question. The team lead, one of the developers and myself, the test engineer.
We went into the meeting room with the longest table available. The team lead had printed out all the epics we had roughly estimated. We placed them on the table in the order of the current priority.
The table, which seats over 16 people, was almost too short.
We went through them one by one, asking questions like, “Can we remove parts of this?”, “Can we remove this from the scope of the release entirely?“, “Can we find other ways to implement this more cheaply?“
We knew that every epic that was removed or made smaller had the potential to introduce new risks.
Wait, risks? Risks as in risk-based testing? Risks that can be used to prioritise testing activities by probability and impact? Maybe this is what we were looking for.
Identifying Risks by Quality Criteria Categories
So we went through each of the papers and asked ourselves: What are the risks of taking an epic, or certain aspects of it, out of the release?
To help us think about potential risks, we used the Quality Criteria Categories from James Bach’s Heuristic Test Strategy Model. This also made it easy for us to categorise our risks and see which aspects of our service would be threatened by them.
We then discussed the likelihood and the impact of the risks we identified.
We had risks in all categories. Removing certain epics would reduce the capabilities, charisma and usability of our service. Others would affect security, reliability and performance. By thinking through these potential risks, we also identified unknowns that we needed to clarify. This was particularly important for epics related to regulations.
When we looked at the risks, we realised that while there were many to consider, some of them were not as threatening to the business as pulling the plug on the project entirely.
Not having a project to keep working on was the biggest risk of all.
Risk Management and Re-defining the Release Scope
Next, we looked at what we could do about these risks if we decided to remove a particular epic from the release scope. We used a ROAM Matrix to do this.
This tool helped us to identify actions:
Resolved: What could we do to fully address the risk while reducing the scope of the release?
Owned: If we have no idea what, if anything, can be done to reduce the risk, who can?
Accepted: What risks are we willing to take without further action?
Mitigated: What could we do to reduce the likelihood and impact of the risk, while reducing the scope of the release?
Each risk was seen as a problem and the questions above helped us to think about possible solutions to these problems.
In the end each epic was assigned quality criteria, risks and actions. This allowed us to change priorities and make decisions about the scope of the release.
After much discussion and thought, we came up with a new plan. A new plan that might keep our project alive. We did it.
Typically, the priority of the backlog is determined by the value it delivers and the effort required to deliver it. Challenging our prioritisation based on risks gave us a much-needed fresh perspective.
This story shows that several tools can be used in combination, and that tools are not limited to a specific discipline.
Have a wonderful day,
Florian