Software is a combination of thousand little pieces that are tagged together by the development team in the hope of working synchronously at the user’s end. To ensure that it will work as intended, testing teams develop a thousand little pieces of their own. Each piece in this phase has a separate duty attached to it. One may be “to write regression test case” while the other may be “testing the newly released build from the development team”. With so many tasks spread across a large team, it can be chaos if there is nothing to guide or direct the members. They may pick things that are not relevant to this current release which would mean their time could have been invested in making the build better.
To apprise each of our team members of the value of a task and keep track of what needs to be done first, we need prioritization. This is achieved through value based analysis or volume based analysis. These two concepts are the core of this blog post that will help us explore how smaller arrangements in adopted software principles can lead to big results.
What is prioritization?
Prioritization is a technique to analyze various tasks and assign them value based on their importance. The values are often represented as “Criticality” in software testing with a dedicated section on bug database websites and of issue tracking systems such as JIRA as well. Once prioritization is completed, the tasks are re-arranged and testers pick up the tasks that are of high priority first.
An example of priority assignment in JIRA
The main motive behind prioritization is to derive maximum value in minimum time from our work. If a task has severe effects on the project, fixing it quickly will reap out more value than the ones that could have waited.
Prioritization is based on a lot of elements that will vary from project to project and the SDLC phase in which it is implemented. For instance, if a locator is changed for an element that has been used repeatedly on the web page, GUI-based suites are prioritized in regression testing.
As this post will explore in the later sections about types of prioritizations in testing, it is safe to mention here that prioritization, no matter which type, will minimize the test run costs as well as the time to produce results. Overall, we get better efficiency and a good return on investment in the future.
What is value driven prioritization?
In simple terms, when prioritization of a certain task (or test) is done based on its value to the project (and to the business), we term it value-driven prioritization or value-based prioritization.
Technically, value-driven prioritization means completing those tasks first that are more valuable. Those that are of lower value are generally stalled for later releases or sprints if the team works in the Agile environment.
When we talk about the value of a task in software, we are juggling between two poles:
- Customer based value
- Business-based value
A customer-based value is that a task is more valuable to us if it is more valuable to the customer. In a few cases, it might not be in the interest of the business and may not return us the invested value in the long term. But if the customer is satisfied, we can always choose this path to keep them engaged in our
application.
A business-based value is that a task is more valuable to us if it is more valuable to the business. In this type of analysis, we are looking at the maximum returns from minimum investments. A business-based value may be the best option for businesses but is often not recommended to be strictly applied as it may not always be in the best interest of customers.
Keeping our process fixed at only one of these methods may not yield the best results. For a good run in the market, a product needs to be customer-centric as well as business-centric. Using a mix of both from above is the responsibility of the scrum masters, product managers, and business analysts.
Elements of value driven prioritization
For someone learning about value driven prioritization, it may look like a straightforward process. Just consider the value of a task based on the selected approach, and everything is done. However, practically, when we work on projects, we need to consider a few elements as well that play a significant role in deciding a value based priority.
Risk
A major influence on deciding a value-driven priority is the risk associated with the task. For instance, if there has been a permission change in your application files and mistakenly in the new release, “others” are also assigned “execute” permissions, this could be fatal for the project. The risk associated is extremely high and can be categorized in the “Severe” risk category. For such high risks, we can prevent ourselves from further digging into this and should assign a high priority to it immediately.
Other factors may have a lower risk and so they should be accounted for but not with a heavy influence. The bottom line is, risks should be analyzed in deciding the value of a task and should play a significant part in the resulting priority.
Dependency
Another factor that is required for consideration in deciding the value-based priority is the task’s dependency on other tasks. If a task has a high dependency on other tasks or other features, etc, then we rank it up in dependency points. This is important because even if a task individually might not contain too much weight, it can create an effect on multiple other tasks which might eventually lead to bigger issues. More dependent tasks would therefore mean a greater value and hence a higher priority.
So finally, we rely on three things to create a prioritized system - the value of the task as an individual, the risk associated with the task, and the dependency it has on the system. A mix of these three pillars decides the final priority and the order in which we should pick up the tasks.
What is volume driven prioritization?
An alternative method to value driven prioritization is volume driven prioritization. In this method, we do not take into account an individual task and determine its value based on the customer’s or business’s interest. Rather, a higher priority is assigned to the tasks that have a higher volume. In this case, the meaning of volume depends on the category we are prioritizing.
For instance, if we need to prioritize a type of testing technique or a type of automation technique, we can consider the volume of test cases set into that particular technique. For tasks that are lined up on the project board, the more tasks in a particular domain, the higher their priority.
Volume-based prioritization is straightforward and we do not determine individual value over this. The idea is that if there is more volume, it is more important and should be finished prior to other work. Practically, in scrums and practices involving prioritizations, volume-driven is not used too widely. This is because of the false idea it may give in certain situations where a task with more volume may not necessarily be as important as a task with a lower one. This can also delay a few tasks that are extremely high priority but are pushed to the backlog.
What type of prioritization is better?
Value-driven and volume driven prioritization are two popular approaches used to prioritize tasks and finish important things first. In the above sections, we highlighted their working methods and the pros or cons they bring with them. Considering both of them side by side, can we declare any one out of them to be better?
Value driven prioritization not only prioritizes based on value but also works on adding value to each of the tasks. This requires deep exploration of not only the task under consideration but other connected (or dependent) tasks including risks associated with all of them. This is the reason that even if only 34% of PEs wanted to create value on day one, as much as 61% inclined in this direction once the project started. Such type of deep analysis is not possible in volume driven prioritization.
Along with these differences in the working methods, we can also safely assume that value-driven prioritization will not provide a false image for any tasks that could lead to delays and stalling of important work. Practically, we recommend working with value-driven prioritization with a focus on not only value but risks and dependencies as well.
Where to implement prioritization?
At last, to explore the areas where we can implement prioritization (both value as well as volume), the following would be the best match:
Testing
The testing phase of software contains a lot of sections with various techniques to implement. The prioritization in this phase helps us decide which phase to go for first. This can depend on the type of software, the team’s skills, or project requirements.
Development and testing practices
Prioritization techniques are also prevalent in practices that are followed in the development and testing of the software. The more prioritized practice is generally followed due to its value which ultimately determines its efficiency in the long run.
Automation
Similar to testing phases, automation too controls a large part of software testing. Prioritized automation certainly hints towards the prioritized test cases and how they are used during testing. A high-priority test case is executed first and is considered to have more value. However, priorities keep on changing with the passage of time.
Requirement implementation
A quick analysis of the requirements helps us assign priorities to them considering their urgency and importance for the business and/or the client. High-priority requirements are implemented first followed by lower priorities. Also, prioritization of requirements is most important in Agile development as regular releases are required in frequent intervals.
Conclusion
Prioritization techniques are used long before they became a standard in software development. From job cards to operating system scheduling, prioritization helps us analyze every task and work first with the one that has more importance.
To apply prioritization in software development, we make use of two techniques - prioritizing through value or prioritizing through volume. In this post, we discussed both of these concepts and the factors that affect the process of deciding a priority. While value-driven is a recommended choice, there is no set standard to follow. A team can follow any type of technique that suits them. With this, concluding the final thoughts, we hope that if not done already, this post will encourage you to include prioritization in the cycle and reap the benefits that it offers.
