Risk Based Prioritization Approach – The Way to Provide maximum value in a short time frame
-
Share:
-
-
-
Risk Based Prioritization is a fundamental step in the quest of providing maximum value in a short time frame. It actually streamlines your entire software development process, if done religiously and effectively. We all know that it’s a critical challenge to find out whether requirements are ‘Testable’ (i.e. Can be tested). It is even more challenging to prioritize them and categorize them in order to plan and optimize your development and testing accordingly.
Do you want to find out whether your requirements are testable? Do you want to understand the criticality of your requirements in quantifiable terms? Do you want to understand the important requirements in your project even before you get into the development phase? & do you want to save money that goes into testing of bugs that could be captured in the earlier stage of SDLC? If yes, Risk Based Prioritization is for you.
It is a process that will enable you to clarify, redefine and prioritize your requirements even before you kick off your development and any sort of testing.
In this article we zero in on Identifying testability of requirements, making your requirements testable, Core Idea of Risk Based Prioritization along with the actual process and its benefits.
Identifying Testability of Requirements:
How many times have you seen that Project Managers or Test Managers are keen to understand whether your requirements are ‘testable’ (i.e. can be tested)? How many times have you seen that your requirements are being reviewed as a ‘Team Exercise’? The answer is ‘It is done very rarely’.
This is one of the critical challenges in Test Management and a threat to your entire Testing Process.
In order to make sure that your requirements are testable, you must make sure that your requirements are Complete, Concise, Correct, Feasible and Unambiguous. If they satisfy these five characteristics, you can confidently say that all your requirements are testable and everybody in your team will be able to understand & interpret them in the same way.
‘Identifying Testability of Requirements’ is the first step of Risk Based Prioritization. Now, the next question is when in SDCL or Agile you should do this exercise of identifying the testability? Well, the answer is pretty straightforward. When you are in your Analysis Phase/ Sprint Planning, it is a responsibility of your Business Analysts to gather all requirements and at that time it is a Testing Team’s responsibility to go through all the requirements and make sure that the requirements make sense and can be tested.
Obviously, when you are in Analysis Phase you would not have identified your Testing Team when you are using SDLC or a Scrum team when you are using Agile. However, the recommendation is to identify at least some of the core team members such as Test Manager, some Test Engineers and Developers who can work on clarifying the requirements.
If all your requirements are testable and you are confident about them, that’s good news!! However, if you have some non-testable requirements, you should try to make them testable by applying Risk Based Prioritization Technique.
Making your requirements Testable:
For Instance, your Requirement Definition says “The application should show a status message or disconnect a user if there is no activity for about 60 seconds”
If you look at this Requirement Definition, you will realize that it has following ambiguities. By looking at it anyone will get the following questions.
- What application are we talking about?
- Should it show a status message or disconnect a user or it should do both?
- It specifies the time interval as ‘about 60 seconds’. So the question is - is it ok to disconnect a user if there is no activity for 50 seconds?
As this requirement has the above ambiguities it can not be tested. Different people on your team will interpret this requirement differently. Your developers may implement something and your testers may end up in testing something else. As a result the end product that you will be putting in to the market will have no value and will have zero customer satisfaction. Thus, your job is to make this requirement crystal clear.
To make it testable you have to list down all possible ambiguities/questions and go back to your Business Analysts to find out the answers. After getting the answers to these questions, your requirements must be updated and the updated Requirements Documentation MUST be circulated within the team. Once this initial exercise is done, we then begin with the core process of Risk Based Prioritization.
Core Idea of Risk Based Prioritization:
Well, Risk Based Prioritization is a process
- To check whether your requirements are ‘Testable’
- To understand ‘What To Test’ for your requirements
- And to ‘Prioritize Requirements’ based on criticality. By the word “Criticality” we mean “Business Criticality” not technical or any other criticality.
The First Bullet of the definition has already been discussed above. By now you must have understood how your requirements are to be assessed against the five important parameters of testability and how to convert them into testable requirements.
The Second Bullet of the definition is ‘understand what to test for your requirements’. It’s a fact that each and every requirement in SDCL has a risk associated with it. Let’s say you have a requirement which says ‘Change the font on your company’s website’. Even though this looks like a very simple requirement, it has some risk associated with it. The idea is to understand the steps to mitigate that risk.
The Third Bullet is the core of Risk Based Prioritization. In Risk Based Prioritization what you do is, you give numbers to some input parameters for each and every requirement. Those input parameters are Impact and Probability.
For example, consider you have 100 requirements. You will give numbers to these input parameters for all those 100 requirements. These two parameters are generally rated in a scale of 1 to 3. 1 being ‘Low’ and 3 being ‘High’.
Impact indicates the importance of your requirement. What are the consequences or ramifications that you are going to face if your requirement fails into production? That is indicated by ‘impact’
For Instance, if an impact is ‘High’, you can rate it as 3. If it’s ‘Low’, you can rate it as 1. In case of a medium impact, rate it as 2. The same logic is applicable to Probability.
Probability indicates chances of failure or chances of errors getting delivered into production. Again, rated in a scale of 1 to 3.
Now, based on the numbers that you have given to Impact and Probability, Risk Scores are calculated for each and every requirement by using the simple formula given below:
Risk Score = Impact * Probability
If you notice, based on this formula, the Highest Risk Score can be 9 (i.e. Impact X Probability = 3*3 = 9) and the Lowest Risk Score can be 1. Thus, your risk scores are in a rage of 1 To 9.
Once you have identified the Risk Scores, we divide your requirements into High Risk, Medium Risk and Low Risk Requirements by Setting up some guidelines very similar to the following.
Please note that depending on a company that you work for these parameters and scoring model can vary.
The left hand side table shows the guidelines that you have set for Requirements Categorization and the table on the right shows various permutations and combinations that you can have along with actual categories such as High Medium and Low. In the second part of our article we will look at the Process of Risk Based Prioritization. Stay tuned.
Yogesh Kshirsagar
