Defining the Value of Software Products Precisely and Quantitatively
The real requirements of a product are not the functions that are needed, or user stories that have to be delivered. It is the possible improvement of performance that customers can get from using the product said Matteo Vaccari. At the XP Days Benelux 2014 conference he facilitated a workshop together with Antonio Carpentieri about defining the value that is needed by customers.
We keep talking about value, yet we rarely stop to think what it really is said Matteo . He provided this definition for value:
To me, "value" is "what the customer really wants", or "what the customer is happy to pay for".
A customer usually has all the functions that they need, a software product doesn’t give them new functions. The difference is not in the functions but in the qualities: how well it does what the customer needs. To make customers happy you need to deliver a product that provides a way to perform the functions better said Matteo.
According to Matteo projects usually fail due to not meeting the performance requirements, hardly ever for not meeting functional requirements.
Matteo gave an example from Kai Gilb for buying a new car. His wife and he would be the main stakeholders who need to become happy with the new car. For Matteo the safety of the car and the top speed provides value, while for his wife coolness and top speed are the most important qualities that the car should have. Together they specified the value requirements. As an example, for top speed they used three numbers: The speed of their present car (100 km/h), the goal for the new car (250 km/h) and the tolerable speed level (170 km/h). With this definition and the quantified definitions for safety and coolness they can evaluate different car types to decide which one they will buy.
The attendants paired up to do an exercise to find out who the stakeholders are, what value is for them and the scale that can be used to measure it. Feedback from one of the attendants was that it can be difficult to focus on values and not discuss functionality. Several attendant explained how they discussed the scales to come to a goal and tolerable level, these discussions provided more insight in the required performance. One suggested to do these kinds of discussions regularly with customers, once some value is delivered and the customers starts using the product the tolerable and goals levels might need to be adjusted.
You need the tolerable level because usually you cannot reach the goal levels of all requirements. Knowing the tolerable levels you can deliver value to customers earlier, you do not have to wait until you reached the goal. Also you can decide if you want to spend more money and time to reach the goal once you are past the tolerable level.