Derk-Jan de Grood explains how a value framework helps determine the relative value of backlog items, how this value assessment can be aligned with organizational goals and strategic ambitions, how stakeholders can be involved in the prioritization decisions and how the value predicted upfront can be checked against the benefits realized upon delivery.
An often-recurring struggle within organizations is the prioritization of items. How do we decide what needs to go first? Of course, the roadmap at the portfolio level can provide guidance, but only to a certain extent. “Highest value first,” said a clever product owner who once attended one of my trainings. However, value can’t always be expressed in money. Do we choose the items that align best with the product vision or the long-term organizational goals? Also, in complex organizations, it’s hard to determine who decides. For example, is it the front-end stakeholder who has the clearest business case or the stakeholder with the loudest voice?
Most organizations know how to determine item size and complexity. For example, by story point poker, T-shirt sizing or just estimating the hours. Prioritizing based on value, however, isn’t mastered by many.
Over the years, I’ve developed the Value Framework. With every organization I worked with, I got the chance to improve it and tune it to their specific needs. The framework helps determine the business value of the epic or features on the roadmap. It makes value estimation more structured and ties it directly to the product vision. This ensures that items align with company objectives and contribute to organizational goals. Ultimately, the framework supports informed decision-making about which functionalities, technical components and other elements need to be implemented.
More controllable
The Value Framework consists of value axes and scoring guidelines. The axes are just a basic set of criteria that drive the value of an item. Within a Safe organization, they may be derived from the Epic Hypothesis Statement. In other cases, they may be based on the business case that’s included in the epic or feature.
Sometimes, it’s challenging to compare different items with each other. For example, one epic might state that it significantly enhances the user experience, while another might not directly impact the user but is still essential, like compliance with regulations. Similarly, technical items might not seem important from a user perspective, but they act as enablers for building other valuable items. By offering different axes, we allow items to be judged based on a variety of benefits. This approach provides a more nuanced evaluation.
After defining the value axes, an important question might pop up: How many points do we assign? In many organizations, scoring guidelines are set up to support these decisions. They ensure that different items are scored consistently, regardless of the person scoring or the time of scoring. Is this a foolproof system? Definitely not. However, experience shows that it’s far more objective and controllable than average estimations made without structured value axes and guidelines.
Different teams may choose to use different guidelines. They need to pick what works best for them. I recall a team working on the intranet site of an organization, having a completely different size of financial impact than their colleagues working on customer-facing products.
Note that the prioritization of an item doesn’t depend on the value alone, but also on its complexity. Just like in Safe’s prescribed prioritization method, WSJF (Weighted Shortest Job First), it’s also important how long the work takes and how time-critical it is.
A good story
The Value Framework can help prioritize the work that needs to be done and may help ensure that people understand the rationale behind the choices made. It becomes more powerful when we link it to the goals of the project or the organization. A value axis can be derived from the product vision and then interpreted as “When we build this item, it’s most likely to contribute to this aspect of the product vision.” But when we link it to the strategic goals, we get an even better picture.
In the book “Resultaatgericht sturen op waarde” (“Result-oriented management based on value”), Erik van Daalen introduces a goal tree to visualize goals and their underlying subgoals. The nice thing about it is that by talking about purposes, we have a great tool to include and involve stakeholders, especially those lacking affinity with IT development.
We might find that the product we’re working on might not cover all organizational goals. This becomes clear when we add the link to the product vision as an extra layer to the goal tree. Although it might be a nice trigger to evaluate the product vision, it might not be a problem at all, since other products and means may be used to reach the other goals. “Attract and retain key talent by becoming employer of choice” and “Develop and activate one brand strategy” are examples of organizational goals that aren’t necessarily covered by products.
As a first step, organizations can benefit from alignment and common understanding. This can be achieved by sharing a good story. At one of my clients, we used a qualitative approach to explain the rationale behind our choices. We did this, for example, during the PI events, to the stakeholders. But also to the leadership and the development teams. As a result, we were all on the same page.
This approach gives us better stakeholder involvement, better alignment between goals and a rationale for why we choose one item over the other. It allows us to have the right discussions to coordinate expectations, set the right priorities and eliminate the waste of working on the wrong things. It helps build trust with the stakeholders and provides guidance for the development teams.
Realized benefits
Determining value upfront is only half the job. The real test comes after delivery: Did the item actually deliver what we expected? We may have scored an item 40 points on operational impact because we expected it to save 16-40 hours a week, but did it also achieve that? If we never look back, the Value Framework becomes a one-time prioritization exercise instead of a learning loop.
This is where benefit management comes in. In practice, I keep it simple: A few months after an item goes live, revisit the value axes it was originally scored on and check them against reality. Did the financial impact axis translate into actual savings or revenue? Did the customer opportunity axis translate into the customer growth or satisfaction increase we predicted? We don’t need a heavy measurement apparatus for this; often it suffices to have a short conversation with the product owner and a look at the relevant metric.
At one of my clients, we built this into the quarterly review. For the top three or four items of the previous quarter, we asked: “What did we say this would deliver, and did it?” It wasn’t always a clean yes. Sometimes, an item scored high on customer opportunity, but the uptake never came, and that was just as valuable to know; it told us our estimation guidelines needed recalibrating or that the assumption behind the score was wrong. Over time, this feedback loop made our scoring more accurate and, just as importantly, made stakeholders trust the numbers more, because they could see we were holding ourselves accountable to them.
It might be better still to align the value with the KPIs of the organization’s performance measurements. Thus, it feeds the practice of continuously evaluating the value of the IT delivery. For some organizations, this might be a bridge too far; they can start thinking value first.
That’s really the point of tying value determination to benefit management: It turns prioritization from a one-off judgment call into a continuous conversation with stakeholders – before implementation, during and after. The Value Framework helps us decide what to build; benefit management tells us whether we were right. Together, they give organizations a much stronger, more honest basis for deciding not just what to work on next, but whether the way they’re deciding is actually working.
