The first principle of the Agile Manifesto says that "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
After 20 years, you'd think that this would be a solid practice within agile teams. But do teams really know why they are building whatever they are building? Do they know what difference they are going to make for the people receiving their solution or what value it will have for end users?
In my experience, many teams still do not have that focus. They talk about quality, as in, “We need good quality in our solution,” “Our customer expects high quality,” and so on. But they don't have a clear picture of what “good quality” means, other than having, say, no severity 1 or 2 bugs and a maximum of 19 severity 3 bugs when going into production.
In other words, there is still a need for a discussion within the team and with your stakeholders about what quality means, although the answer is probably not obvious to everybody, and you don't necessarily share the same picture.
But it is never too late to get started with that discussion. Here's how the VOICE model can help get you there.
What is quality?
There are several formal definitions of quality. For example, ISO 25010 lists several different attributes of quality, depending on whether you talk about product quality or quality in use. But Gerald Weinberg had a very simple definition of quality, later refined by James Bach and Michael Bolton:
Quality is value to some person, at some time, who matters.
To get an idea about what quality is in your context, start by figuring out who the people are who matter. End users, customers, product owners, marketing people, salespeople, support people, etc. all have an idea of what value means. But you need to identify the right set of stakeholders with whom to have this discussion.
When you have an idea who they are, then you can start discussing what value is to them, which brings us to the VOICE model.
The VOICE model
First introduced in the book Quality for DevOps Teams, by Rik Marselis, the VOICE model is the successor to the goal, question, metric (GQM) model. VOICE stands for value, objectives, indicators, confidence, and experience. It gives you an approach for having that important talk with the people who matter about what they expect, how to make the goals measurable as objectives, and how to use them as pointers for figuring out whether you are delivering the value the stakeholders expect to receive.
The purpose of the VOICE model is to establish confidence that the pursued business value can be achieved. Here's what the model looks like, along with an explanation of each element:
Source credit: Sogeti
Value: Whatever you are developing is meant to add value to someone somewhere. That value should be defined by you and your stakeholders, and it should be visible to you. In the process of defining the value, you will often identify implicit expectations for the solutions, and you will have the opportunity to make them explicit when defining the pursued value.
Objectives: Once you have identified the sought value, you need to translate it to quantifiable objectives in order to properly understand the purpose of the system under development.
Indicators: As a team, you need a way to measure whether those objectives are met and whether the pursued business value will be achieved by meeting them. You can do this by identifying specific indicators. The primary way to measure these indicators is to test the solution.
Confidence: With the output of testing and the measurement of indicators, you can supply information to your stakeholders so that they can gain confidence that the solution will give the sought value.
Experience: No matter how many indicators you have, the best place to figure out whether the system gives the pursued value is by gaining experience, using the system in practice. Based on the end users' practical experience with the operational use of the system, you will get feedback, and you might also identify further areas that need improvement. This will then trigger a new cycle of the VOICE model, the value improvement loop.
How to use the VOICE model
Theories and models are one thing, but how do you use the VOICE model in practice? When you start a new iteration, a new project, a new increment, or a new feature—whatever level suits your context the best—the discussion about value should take place at the point of identifying the scope. Get a solid, common understanding of the scope and what value it should bring, not just the practicalities of what the features are supposed to do in terms of functionality.
For example, you goal could be “We want to give our sales staff a more effective way to register orders in the business-to-business part of our company” or “We want to give our customers the possibility to pay for their orders using a credit card.”
Both are realistic goals for a new order system, but they might be difficult to measure. So you need to take them one step further and create measurable objectives.
For the first goal, objectives could be:
- Registration of an order must be possible by use of keyboard only (which is more effective).
- Validation rules must be set up for all fields in the order window.
For the second goal:
- It must be possible to pay with the following credit cards: Visa, Mastercard, and American Express.
- The payment must include the verification method of the credit card company.
- The credit card payment should not take more than twice the time other payments take.
These objectives can be used as a foundation for your quality risk analysis as well, making it possible for you to visualize the quality risk related to each. But most importantly, with the objectives defined, you can now specify the indicators necessary to verify whether the objectives have been fulfilled or not.
A couple of recommendations related to the indicators:
- Don’t have too many; five to 10 should be the maximum (with a preference for fewer).
- Indicators should never be a static set; reconsider them regularly, maybe every three months or so, to be sure that you have the right focus.
A couple of examples of indicators that could support the communication around fulfillment of objectives could be:
- IT-related indicators:
- Test pass/fail ratio (organize the test so that the objectives can be identified from them, e.g., a test suite handling the validation rules for the first goal, and one covering navigation. For the second goal consider organizing test cases per credit card type)
- Quality risks mitigated compared to quality risk identified (as mentioned, use the objectives as input for your quality risk analysis, making it possible to communicate targeting each of these)
- Problem-related indicators:
- Number of anomalies identified in test grouped toward the objectives
- Mean time to investigate and fix problems compared to agreed level
If you look at the indicators above, they are not that different from what you are used to. But the way you organize the data foundation for them is essential to be able to communicate about the state of each objective.
As a part of the testing, you can now document the result of the indicators and communicate the result to your stakeholders to give them a foundation on which to decide whether they have confidence in the solution and are ready to send it into production.
With this approach, you create a thread, from the goals and values of your stakeholders through the indicators you use to evaluate the solution created, and you can communicate with your stakeholders based on those goals/values, rather than using a standard set of measurements and metrics that you reuse from project to project.
Use the VOICE model for a value-driven approach to IT delivery that ensures that what your stakeholders really need is the center of attention in the team during the entire lifecycle.
Want to know more? During my online EuroStar conference session, "Quality is not about testing … It’s about value!" I will take you through the VOICE model and introduce a structured and interactive method to identify the right metrics, based on an understanding of what your business needs and what it defines as the objectives for testing for your team. The online conference runs September 28-30, 2021.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
