What are Value Stories?-EN

That value and value management is a critical aspect of any organization is self-evident.

It is also evident that valuing value, and measuring it in an objective and consistent way is difficult. Even if we use entities such as CoD (Cost of Delay), it is hard to measure value.

Even if we translate it into cash revenue, we know that many valuable actions are not easily converted into monetary value (for example, improving the external perception of our organization to attract talent or increasing the trust of our customers).

Furthermore, value fades easily. With a change of strategy, guidelines, context, value vanishes. In a product or service under construction, the boundary between the expected value and waste (when it is no longer needed or when it does not arrive on time) is easily crossed.

The concept of “value stories” (or VS) is not a magic solution. But it does help in managing value and the work required to achieve it, for example, in portfolio management or VSM (Value Stream Management).

This concept is described, in more detail, in several places. In this article, we take as a reference the book “The Journey to Enterprise Agility” by D. Kulak and H. Li, a recommended reading, that brings to Agility a technical view from the Systems side.

Defining Value Stories

At this point, there is no need to explain what a user story is. A value story has a similar structure, but its objective is to connect the ROI (Return of Investment) with the work developed by a team during the construction of a product or service.

A value story can be viewed as a group of user stories, but it is not an epic. VSs follow this format:

As <a company>, I want to <create something> to <achieve something>

A couple of possible examples would be:

• “As GoodERP SA, I want to include an asset management functionality to increase my product sales by 5 to 10 M€.”  
• “As MediumFactory SL, I want to redo my order system to be able to eliminate the old one and save at least 600 K€”.  

Although they seem to be a shorthand form of Business Case or statements about ROI, you can see how there is no mention of the investment needed.

Some things to keep in mind about value stories: 

• Value stories are created at the beginning of a work cycle (version, delivery, release) to organize the backlog. 
• There can be several value stories in each product version or release, but they are not a unique or exclusive goal. 
• A value story does not have to be limited only to economic benefits. They can also include other objectives such as customer satisfaction, company image, or time reduction. If they describe an economic benefit, they may also include revenue or savings, and in those cases, ranges can be used to avoid a false sense of accuracy.
• Value stories are not static. They can change as the team and stakeholders learn more about the problem and the solution they are building. 
• Value stories are not epic: a user story can be part of one or more value stories. Sometimes, completing the work needed for one value story completes the work needed for another. 

What are value stories good for? They help in prioritizing user stories, especially when our product is big and we have a large number of user stories.

Unlike epics, which describe the main features of a product or service, value stories tell us what the organization is trying to achieve. Value stories provide information about the end-to-end and are a way to provide information about the purpose, which is very important to generate alignment.

Managing Value Stories

VS can be prioritized, while at the same time helping prioritization. For this prioritization, we have decisive information, which is the associated ROI, but it does not have to be the only criterion.

On the contrary, it is advisable to at least combine it with effort, time criticality, and some other criterion to avoid that, for example, very necessary activities, but of a technical or internal nature, are not prioritized because they do not have an associated VS.

In these cases, it is usually advisable to reserve effort for, for example, solving technical debt or carrying out activities that improve working conditions (training, tools, new capabilities, experiments).

Sometimes the value stories are large, which makes it difficult to work with them. It is possible that they cannot be carried out in a given period. That is why it is worth splitting them up.

Splitting value stories may mean that you will not get all the expected value until all parts of the story are completed, but at least you will get some of the expected value. In splitting VSs, you can apply techniques already known from splitting USs, such as:

• Functionalities. 
• Customer segment. 
• Non-functional requirements. 
• Quality levels. 
• Connection with other components and systems. 
• Use cases.

The value of Value Stories

Using value stories helps provide intent and vision in the process of building or developing products and services. ROI and Business Case calculation is often left in the drawer (and head) of the finance team, removed from the knowledge of the people who make the Business requests translate into something tangible. Instead, the Value Stories provide valuable information available to anyone at any level.

They are also a point of contact and a common language between business and technical people, helping to bridge one of the most damaging divides within organizations. They are a way to focus on results or outcomes and not only on outputs.

However, we must also be aware that, when it comes to measuring its effectiveness, ROI tends to move in much broader time frames than those determined by a delivery, release, version, or product evolution.

It is, therefore, advisable to combine it with other types of outcome-oriented metrics or to structure it temporally to avoid generating unnecessary frustration if the objective is not achieved immediately.