Agile

The Business Value of an Agile Retrospective

Luis Ortiz

— 6 min read
The Business Value of an Agile Retrospective

Are you aware of how much value your work adds up? Individuals and teams need to have a concrete idea of their impact in any business environment. But how do you measure value?

At first thought, some could consider profit and value as synonyms. Equating how much revenue can be attributed to a person or team may be tempting, but it doesn't always make sense. Value is contextual: What is considered valuable depends on circumstances, objectives, and culture.

For an Agile team, it's crucial to understand and constantly reflect on what is valuable and how they can deliver it to customers and stakeholders Retrospectives are perfect for this end. Find out how.

Topics to check

  1. Defining Business Value
    a. Tangible Business Value
    b. Intangible Business Value

  2. Business Value in Scrum
    a. Product Value
    b. The Value of Agile Retrospectives
    c. Action Items

1. Defining Business Value

If you think that the finances and products of a company are its value, those would instead be considered assets. To state it better, we'll stick to Robbin Schuurman's answer to the question What is Value?. He suggests that it comes in many forms, is context-dependent, and may change over time.

There are three principal scenarios in which we can consider value:

The value delivered to a customer - How well does a product or service satisfy customers' needs?

The value delivered to an organization - What is the company getting in exchange for satisfying the customers' needs?

The value delivered to a collaborator - What is an individual getting in exchange for collaborating with a company to satisfy customer needs?

Those three variables are always dependent on each other. In this triangle, each shackle delivers and gets some value, which we haven't precisely defined yet. But understanding the conditions is the starting point, as the value in Agile-focused companies always depends on the circumstances.

Stating who will benefit from the value delivered is an essential foundation to having a more concrete vision of what it actually is. We can establish a dual categorization:

Tangible Business Value - What can be clearly measured with numeric metrics.

Intangible Business Value - What can be perceived. It may be possible to measure qualitatively or quantitatively.

Let's dig deeper and check some examples.

a. Tangible Business Value

This category refers to all those forms of value that can be (almost) precisely measured, often with quantitative methods.

Some examples are:

In terms of value delivered to a customer:

  • Daily Active Users / Monthly Active Users
  • Customer Lifetime Value

Regarding value delivered to an organization:

  • Revenue Growth
  • Return on Investment

Considering the value that a collaborator may get:

  • Salary Growth
  • Decreased Work Effort

b. Intangible Business Value

The forms of value that aren't as straightforward to measure but can be perceived. Some examples are:

In terms of value delivered to a customer:

  • Customer Satisfaction
  • Product Safety

Regarding value delivered to an organization:

  • Company Reputation
  • Risk Avoidance

Considering the value that a collaborator may get:

  • Employee Satisfaction
  • Legal and Contractual Compliance

Now that we've got a general idea of how value is represented in a business context, we can review it in Agile terms.

2. Business Value in Scrum

Good practitioners of any Agile framework should clearly understand that shipping a product isn't the same as delivering value. According to a study run by CleverTap, 39.9% of mobile users uninstall an app because they don't use it.

In the words of marketing specialist KC Karnes:

"Overwhelmingly, users are uninstalling apps because they simply do not use the product. This could mean your engagement and retention efforts are ineffective or signal bigger problems with the value proposition."

Being incapable of delivering value to your customers limits how much an organization or collaborator can get from it. That's why Scrum focuses on providing tangible increments for each sprint or work cycle -increments must be testable. This prevents significant risks and leads the team to constantly validate the value the product or service can bring.

For example, while developing an app, tasks that add more value at an early phase may be focused on the technical setup. We can expect Business Value to change after the first version has been deployed, maybe due to bug leaks or user feedback.

a. Product Value

One of the primary responsibilities of a Product Owner (PO) is to maximize value. The Scrum Guide puts it this way:

"The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team."

As the main link between the organization and the Scrum team, the PO must ensure the product includes the required features and is developed within expected timeframes and costs. The PO does that by prioritizing the Product Backlog, which includes items or Stories that must be delivered to address the customers' and stakeholders' needs.

The EBM (Evidence-Based Management) framework helps understand the value any product can deliver by considering four main criteria:

Current Value - How much value is being currently delivered to customers?

Unrealized Value - How much value could be delivered by meeting the customer's potential needs?

Time to Market - How quickly can an organization deliver new features or products to meet customer needs?

Ability to Innovate - How capable can an organization deliver a product that satisfies customers' needs more efficiently?

Specialist Sunil Gulia thinks, as we stated before, that product value is contextual, but two elements may be a constant:

The Return on Investment is the reason a company creates and supports products or services.

  • Being able to perform a job or activate is why a customer can acquire a product or service.

  • Any successful business centers its efforts on achieving both.

b. The Value of Agile Retrospectives

What happens when you aren't quite there? Maybe the product is not sticky enough, has low engagement, and fails to bring a healthy Return on Investment. The Product Owner is responsible for maximizing its value, but the support of the whole Scrum is needed to execute the items that will mitigate product adoption anti-patterns.

In this sense, gathering after each increment has been delivered to run a Retrospective session improves the processes required to provide and maximize value. In this discussion, each member must say what they considered went well, what didn't, and what could be improved for the successive work cycles.

Retrospectives are ideal forums for the team to check on delivered value, not at a feature level (that's a matter for the Sprint Review), but with a more high-level perspective.

Consider a situation in which a Storie was supposedly completed but required some tweaks due to lack of clarity, compromising the delivery of a value increment. That's something you want to tackle during a Retro.

It is not about proving to your manager that holding a session at least once at the end of each sprint is not a waste of time. It is about your team getting Action Items as a concrete outcome.

c. Action Items

For Ben Linders, co-author of the book Getting value out of Agile Retrospectives, coming up with Action Items tends to be more successful when those selected are feasible and few. It is a no-brainer: Limiting your Items will give you more time and staffing to complete them.

We would also suggest making sure the tasks get done. Otherwise, they might go overdue.

Learn more on how to effectively follow up on Action Items in another of our blog posts.

A reliable KPI to understand the business value of your Agile Retrospectives is the number of Action Items that were effectively completed or dropped during the next sprint.

Imagine getting a task drop rate of 4 out of 5: It could tell you that you are not selecting the correct Action Items to follow up. But how to calculate it is up to your team.

One effective way to follow up on Action Items inside your projects is to pick up the Agile Retrospectives app. It is a solution for teams that want to take their Retros to the next level, available for Jira, Confluence, monday, and Trello. Just export them and follow them as you would do with any task.

In conclusion

Business value is always contextual, and the metrics used to measure it depends on the objectives of the organization and the market it serves. In that sense, the business value you can get from retrospectives has to be aligned to your key performance indicators and business goals.

That will increase the value of solving follow-up action items.

Remember to keep the number of action items within a reasonable limit. The less, the easier it is to implement them. It'sIt's senseless to have a list of 10 things just for the sake of it.

More about Agile Retrospectives:

Check out our tools:

Stay on top of our upcoming releases:

And subscribe to our blog below!

Read more