In my last article, I talked about how trust is the secret ingredient to high-performing product teams. The article stated that as a stakeholder you have to trust your team by empowering them to self-organize, take ownership, and solve the problem at hand. The question I was asked following that article was, “Great, but once I have a high-performing team, how do make sure they are delivering business value?”

As former President Ronald Reagan used to say, “Trust, but verify.” Now President Reagan was dealing with nuclear disarmament with Russia, so unleashing a high-performing product team without verifying results wouldn’t be quite as bad, but it can be a very explosive situation for your organization when not managed and trust is lost.

So how do you verify the results of an product team? There are many ways to measure value, but they all boil down to two groups: subjective and objective. Both have their strengths & weaknesses and to get the best results I recommend a combination of each.

Breakout the planning poker cards, we’re talking Business Value Points. If you have been around any team that uses the framework Agile Scrum, you have probably seen how they come up with Story Points. Using the Fibonacci sequence (Fn = 1, 2, 3, 5, 8,13, 21) the team votes on the number of Points the story is worth. For developers, those Points represent a combination of work volume, complexity, and uncertainty.

Unlike Story Points, Product Managers and Stakeholders get to play planning poker when it comes to Business Value Points. Business Value Points should represent a combination of cost reduction, sales increase, and risk mitigation for your planning. You point the stories relative to each other in this game.

I find it best to figure out what is a “middle-of-road” valued story and assign it a Business Value Point of 5. Then asking the stakeholders to compare the value of the next story to that story allows them to quickly and easily point the stories.

Holding a Business Value Pointing session between your backlog refinement sessions with stakeholders is not only fun, but it keeps the stakeholders very engaged. It also gives them a deeper understanding of what is going on and how the product team creates Story Points for stories.

This process is not limited to User Stories, you can also apply this to Features (group of user stories), Epics (group of features), or even Products as a whole.

The neat thing is, that as a Product Manager doing this makes prioritizing a no-brainer. With Story Points representing “Effort” and Business Value Points representing “Benefit,” it is now just a simple Effort-Benefit analysis.

You can even calculate an “ROI” for each user story by dividing the Business Value Points by Story Points. While this isn’t a true Return On Investment it gives you a great idea of what stories are going to give you the biggest value boost.

Product teams also love this! When a team knows that stakeholders believe a story they are working on is valuable, it gives them a sense of pride when it gets delivered. And now, as User Stories, Features, and Epics are deployed into production, business value can be measured simply by adding up the Business Value Points delivered.

What one factor are you trying to affect with this product or feature? When you set out to pull this team together to build, what was it that you as a stakeholder or product manager were you trying to change? For some, this is hard to verbalize. You know in your gut that this will be valuable, but how?

In our previous section were talking about the subjective results of cost reduction, sales increase, and risk mitigation. These factors together represented business value points. The goal here is to more clearly objectivize these factors.

Thinking about each factor, develop a hypothesis for how value will be delivered. You will likely need to make some assumptions, and that is okay. Do your research and figure out how the project can have a positive effect on your company. As the expert, you have to just put a number out there and let others, who may disagree, come up with a valid reason it isn’t right.

Now armed with the factor that you know will show value, you will need to measure this factor throughout the product. Being sure to get a measure at the start and every time the product team delivers features, you can now confidently know that value is or isn’t being delivered.

Taking the gut feeling out of knowing if business value is being delivered gives you a certain indicator that you are doing the right thing. If the factor you are measuring stays flat, or worse goes in the wrong direction, it is a time to pause, stop, or pivot in a new direction. However, be sure to give your measured factor enough time to settle after a deployment. It can take some time after a deployment for things to normalize, so don’t jump the gun.

Using objective verification can also get you to a product ROI/IRR. Knowing what your product team, infrastructure, and ongoing services will cost, you can compare them to your assumed delivered value. If you know you truly have a winning product but are having a hard time selling it internally, there is nothing more convincing than plopping a product worth an IRR of 300% or more in front of your CIO/CFO. With all of the research and product breakdown you have done, it will be hard to argue.

This level of analysis isn’t something you’ll want to do on each user story, maybe not even each feature, but at the epic and product level, objectively measuring value is important to know that you are headed in the right direction.

We’ve established that you can get a high-performing team by trusting their ability to self-organize and deliver value, but in this article, we talked about how to verify that what is being delivered is really valuable to the business.

Both subjectively and objectively verification has its pluses and minus. So what I have found is that using both is ideal. Using Objective verification at the Epic and higher levels gives you the confidence in certain results while not being overly time-consuming. Then using subjective verification at the Epic and lower levels give you the quick and easy sniff test that aids in prioritization. I like to do both objective and subjective verification at the Epic level as quick and easy prioritization of epics can be quite beneficial so you know what should be fleshed out first.

Have stakeholders play planning poker assigning Business Value Points which represent cost reduction, sales increases, and risk mitigation to Epics, Features, and Stories for quick and easy prioritization. But also determine the one measurable number that will change upon successful delivery of Products and Epics to know true value is being delivered.