The Art of Product Management
The phrase “There is an art to this job” usually means there is something opaque about it that can’t be easily defined.
By:
trust /trəst/
noun
In my last article, I talked about how trust is the secret ingredient to high-performing Agile 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 I make sure they are delivering business value in agile?”
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 Agile 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 agile trust is lost.
So how do you build verification tests in an agile project? There are many ways to measure business value in agile, 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.
Strengths: Quick and Easy
Weaknesses: Personal Bias Curves Results
Breakout the planning poker cards, we’re talking agile business value points. If you have been around any Agile team, 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 (business requirement) is worth. For developers, those Points represent a combination of work volume, complexity, and uncertainty.
Unlike Story Points, Product Owners and Stakeholders get to play planning poker when it comes to agile 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 for business value estimation in agile.
Side Note: People are really bad at estimating, but they have a keen ability to relatively compare things. If asked, “How much money will moving the submit button from the left to right make the company?” A stakeholder has no idea. However ask them, “Does moving the button have more or less value than adding a new payment method?” This is much easier.
I find it best to figure out what is a “middle-of-road” valued story and assign it an agile 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.
Fun Fact: There is no upper limit for the Business Value Points you can assign. For Story Points, if something is bigger than an 8, you have to break down the story. But for Business Value Points, because you should have already sized the stories with the team, the higher the better!
Holding an agile 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 Agile team creates Story Points for stories.
This practice is not limited to agile user stories, you can also apply this to Features (group of user stories), Epics (group of features), or even Products.
The neat thing is, that as a Product Owner 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.
Agile 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 in agile can be measured simply by adding up the agile business value points delivered.
Strengths: Certainty of Results
Weaknesses: Time Consuming and Hard
What one factor are you trying to affect with this project? When you set out to pull this team together to build, what was it that you as a stakeholder or product owner were you trying to change? For some, this is hard to verbalize. You know in your gut that this project will be positive, but how to measure business value in agile can be the tough question to answer.
In our previous section we talked 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 in measuring business value in agile.
Thinking about each factor, develop a hypothesis for how business value in agile will be delivered. You will likely need to make some assumptions. 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.
For Example: If you think that a project is going to reduce the time it takes for an operator to perform a task from 3 minutes down to 3 seconds because you have done a time study. You can calculate what that operator makes per hour, how many times the task is done per hour, multiply that by the number of hours in a year to get a yearly cost reduction value.
Now armed with the factor that you know will show project value and verification and validation in agile, you will need to measure this factor throughout the project. Being sure to get a measure at the start and every time the Agile team delivers features, you can now confidently know that value is or isn’t being delivered while measuring agile team performance.
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 in an agile performance measurement, 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 deployment. It can take some time after a deployment for things to normalize, so don’t jump the gun on quickly measuring business value in agile.
Using objective verification can also get you to a project ROI/IRR in analyzing agile business value metrics. Knowing what your development team, infrastructure, and ongoing services will cost, you can compare them to your assumed delivered value. If you know you truly have a winning project but are having a hard time selling it internally, there is nothing more convincing than plopping a project worth an IRR of 300% or more in front of your CIO/CFO. Exceeding key performance indicators kpis for measuring business agility in addition to all of the research and project 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 business value in agile 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 subjective and objective verification and validation in agile development 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 Feature 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.
TLDR;
Have stakeholders play planning poker assigning agile 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 Programs, Products, and Epics to verify business value in agile.
Design cutting-edge software and digital experiences for America’s most admired brands with Nexient.
.svg)
