Conceptually, value is fairly simple. Value is a measure of importance or worth. This is where simplicity ends and complexity begins. To determine worth and importance we have to understand the difference between the perceived cost and the perceived benefits. Here is the value equation:
Value = (Benefit + Perception) – (Cost + Perception)
Cost, benefits and perceptions are like a suitcase; they are containers with many different things inside. Let’s unpack those suitcases just a bit.
Thinking like a cost accountant is useful when considering the cost component of the equation. The typical costs that are accounted for when costing an IT project include labor, materials, hardware and overhead. Each of these categories could easily be broken down even further. For example, labor can include internal labor (cost of employees) and the cost of contract or outsourced labor. The cost of all labor needs to be considered. I once ran into an organization that only considered external labor when deciding which piece of work should be done. This caused the firm to make economically unbalanced decisions that reduced the value that they delivered to their clients. Far less typical, but no less relevant, costs that need to be assessed when determining value include opportunity costs, business costs and legal and risk mitigation costs. Opportunity costs represent the benefit that would be gained from the work that is foregone to another piece of work. All work has an opportunity cost. Ranking portfolios of possible work by importance is a way of incorporating perceived costs into real costs.
Interestingly, benefits are often far less tangible than costs. Benefits are always predictions of the future, and therefore are more apt to be impacted by perceptions and cognitive biases. Depending on the type of effort, typical benefits often include improvements in market share, cost savings and revenue enhancements. The forecast of benefits is the result of some form of transformational magic that leverages the predicted impact of a change (what will happening if a piece of software is used) and the probability of use (will it be used and how fast will the uptake be). The transformational magic can be incredibly formal based on market research and statistical interpretation or a reflection of gut feel.
The third component of both benefits and cost is perception. Perception means how we regard, interpret or understand a cost or a benefit. Perceptions is the bucket of factors that reflect all of the biases or gut feels with either the cost or benefits. For example, a financial projection might indicate that a feature will deliver $1,000 of value however the might temper that projection based on his or her feeling about the direction of the market. Techniques such as template driven cost/benefit analyses, parametric estimation, planning poker and Delphi estimation try to ameliorate the impacts of some types of less rational perceptions. Overly optimistic estimation of costs and benefits are types of less rational perceptions (read Optimism: The Good and The Bad).
Value is a shorthand mechanism to reflect the difference between benefits and cost based filtered through the perceptions of those collecting and analyzing the numbers. Value is important to concepts ranging from qualifying which feature to work on (part of #NoProjects), selecting user stories for the next sprint (sprint planning) or as prize for getting code into production as fast as possible (#NotImplementedNoValue). These represent only the tip of the iceberg for how value is used in Agile. Without a firm grounding what the word value means it is difficult to ask a product owner what the value of a particular feature is and then help evaluate the answer.