Are you feeling overwhelmed as a product owner, business analyst or architect trying to determine the most crucial features for your product? Look no further! This article offers a comprehensive introduction to requirements engineering in an agile environment. By delving into the basics of this field, you will gain some relevant knowledge and insights on measuring the value of qualities in order to make informed decisions and create a successful product roadmap.
Value and Scrum
According to Scrum, a Product Owner is accountable for maximizing the value of the product. Where the focus used to be more with the product, Scrum has moved more and more to a value focused approach. One could even go as far as saying the product is merely a vehicle to deliver the value.
Value is the reward for solution of problems, the satisfaction of wants and needs.
– Peter Drucker
Value you say?
In IT we often see technical solutions or functions of a product as value, but it’s the qualities of the product where the value lies. With any given product, it’s the qualities that dictate the interaction with the product and therefore the value of the product. Using the example of a smartphone, one could argue that the value is strongly related to the function, but once we dig deeper, qualities such as reliability, affordability, ease of use and design are what drive the value.
So, if value is so important, how do we go about maximizing it?
Whatever the product is, if we want to increase value, we first need to understand the qualities related to the product. Is it important the product is easy to use? Is it important that the product is reliable? Or is it more important that the product is cost efficient? Once we know the important qualities, we can start maximizing.
Quantifying
If we know what is important and we want to maximize it, make it higher, we need to first understand where it is now. And to understand where something is now, we need to start measuring. But before we can start measuring, we need to establish how we will quantify the qualities of a product. This implies that all qualities are quantifiable, which can be difficult sometimes.
According to Tom Gilb (a fundamental author in the field of requirements engineering), everything is quantifiable, as he explains in his Ted Talk:
Scales
In his book, Competitive Engineering (one of the landmark books on requirements engineering) Tom Gilb uses a so called Scales to quantify stakeholder values or product qualities. A Scale, Scale of measure or Quantification Scale has the following elements:
Stakeholders: Which stakeholders of the product get value from this quality.
Unit of measure: The variable that will be measured, for example; euro’s, kilo’s, seconds, purchase orders, etc.
Rate: The rate of the variable, for example; per order, per 100 units, per visit, etc.
Description: The description of the scale, for example; time spend doing an activity, spend on product category, etc.
A good scale is explicit and doesn’t state a quantity, for instance; “% of offers converted to orders.” The example; “60% of offers converted to orders”, would be a bad scale, because it is already quantified. Above all, the function of the scale is to be a literal “scale” on which we can plot our data points.
| Quantification Scale | Desired Change | Metric |
| Customer Satisfaction | Fewer received complaints | Number of complaints about [Product] within a [Period] |
| Customer Satisfaction | Fewer returns | Percentage of returns of [Product] within [Period after purchase] with [Customer issue] |
| Environmentally Friendly | Improved rating | Number of [Product types] that fail [Test] within [Period] |
| User-friendly | Fewer mistakes | Percentage of [Transaction type] with [Error] made by [User type] |
| User-friendly | Faster certain action | Time in minutes to complete [Transaction] to satisfaction |
| Reliability | Fewer outages | Mean Time Between Failure (MTBF) |
| Predictability | Less variance to first response | Percentage of [Service Type] calls that exceed [First response] within [Period] |
Meters
Now that we have a scale, we can start measuring to know where we are currently. And to measure we need data.
Without data, you’re just another person with an opinion.
– Peter Drucker
To get relevant data to plot on our scale we need to start measuring. Defining a scale itself has no cost, but measuring with a so called meter, does have costs. This meter or measurement can be either a process or a tool with a cost, accuracy, delay and believably. When selecting a meter it is important to evaluate these factors to make sure it fits the job. Measuring customer satisfaction can be done by a simple check with a few select customers, or by implementing a user rating feature.
If we can quantify the value of something and we can measure it, we can also track if solutions that we build, have the impact on the qualities that we expect. As long as we keep measuring the realization of the expected increase in value, we know where we are on the scale. Of course the characteristics of the meter need to be kept in mind when evaluating these measurements. A point often overlooked is the delay of a measurement. Defining the right scale and staying mindful of the characteristics of the meter are essential.
Let’s compare apples to oranges
If we know the values or the preferred qualities of our product according to the users or stakeholders and we can quantify and measure them, we can ultimately compare them. This enables a product owner to select which features of a product to focus on. The expected benefits of a specific feature, weighted against the costs can help a product owner prioritize and order backlog items based on their relative added values.
Backlog prioritization
How do we use requirements engineering to apply all these concepts to the task of prioritizing a backlog? If we know which values we want to achieve and which qualities drive these values, we can order the values based on their importance. For example, the value of a smartphone may be greatly impacted by its design and ease of use, while the value of a car may be more affected by its reliability and fuel efficiency.
It’s important to consider the weight of each quality to accurately evaluate its contribution to the value of a product.For instance, if a company is developing a new software, it may prioritize developing a user-friendly interface as the most crucial quality, as it is more likely to drive more value for the product compared to other features. Implementing a new feature can improve one quality, but also multiple. Taking in mind the weights of each quality, the best feature will be the one that adds the most overall value.
Feature value formula:
Feature value = (Weight of Quality 1 * Impact on Quality 1) + (Weight of Quality 2 * Impact on Quality 2) + ... + (Weight of Quality n * Impact on Quality n)
Where “Quality 1”, “Quality 2”, …, “Quality n” are the different qualities that impact the value of the product, and “Weight of Quality 1”, “Weight of Quality 2”, …, “Weight of Quality n” are the weights assigned to each quality based on their importance. “Impact on Quality 1”, “Impact on Quality 2”, …, “Impact on Quality n” are the estimated impact of each quality on the value of the product.
In order to prioritize these values we only need to divide the Feature value by the Cost of implementing the feature:
Priority = (Feature value) / (Cost of implementing the feature)
One last variable that could be used to impact the priority is the time used to implement the feature, although one could argue this can be factored into the cost of the implementation. Delivering product increments to gather feedback is a crucial aspect of Scrum, so a feature that can be inspected regularly and consistently is preferred.
Now show me!
Let’s say we are prioritizing new “smart grid” features for an IoT platform. We have two possible new features; a data product that enables predictive maintenance and a data product that enables heat grid optimization. The values/qualities, scale, status, goal and relative weight are defined using requirements engineering in this example as following:
| Quality | Environmentally Friendly | Cost Reduction | Reliability | Customer Satisfaction |
|---|---|---|---|---|
| Scale | Average Coefficient of Performance (COP) per year | % Distribution Loss per month | Mean Time Between Failure (MTBF) in days | Number of Complaints about heating per 100 households per year |
| Status | 3,5 | 20% | 41 | 12 |
| Goal | 4 | 14% | 100 | 3 |
| Weight | 60 | 20 | 10 | 10 |
Then we can quantify the expected impact of each feature or backlog item, percentages are used to indicate the relative change compared to the status and goal:
| Backlog item | Environmentally Friendly | Cost Reduction | Reliability | Customer Satisfaction |
|---|---|---|---|---|
| Predictive maintenance | 0,05 (10%) | -1% (17%) | 60 (102%) | -6 (67%) |
| Grid optimization | 0,3 (60%) | -3% (50%) | -5 (-8%) | -3 (33%) |
To finally calculate the priority based on the ratio or expected benefits and costs where the average benefit does not keep the relative weight of the quality in mind but the weighted benefit does:
| Backlog item | Cost | Avg. Benefit | Weighted benefit | Priority |
|---|---|---|---|---|
| Predictive maintenance | 8 | 49% | 26% | 0,033 |
| Grid optimization | 13 | 34% | 48% | 0,037 |
Using the example above, grid optimization has a higher priority based on it’s cost benefit ratio even though it has an expected negative impact on Reliability.
When you can measure what you are speaking about, and express it in numbers, you know something about it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.
– Lord Kelvin
Takeaways
All in all the job of the product owner is to maximize value. To maximize value, the product owner first needs to understand stakeholder needs and the qualities of the product. Stakeholder needs to use requirements engineering to quantify and measure the value of a feature. Only then the product owner can balance different values and maximize between them.
I would like to thank Bas van der Hoek from Zilverline and his excellent training on requirements engineering and for introducing the topic to me.
