In today’s Agile Coaches’ Corner podcast episode, host Dan Neumann is joined by returning guest and AgileThought colleague, Adam Ulery. Adam is a perpetually curious, continuous learner who is always willing to encourage others to try new things (as he very often does himself). He’s a senior agile coach and investor in multi-family properties. He’s focused on helping organizations clarify and meet their business outcomes and loves to help companies become resilient, rediscover curiosity, and change their traditional approach to business.
Today they will be discussing Business Value Points (BVPs). Business Value Points are a way for leaders, sponsors and funders of a project to measure progress. It enables them to understand the progress being made toward building their product. Adam shares a more in-depth look at what BVPs are, explains why we should care, and breaks down what they measure. He also provides numerous practical tips and methods for generating BVPs for Product Backlog items.
Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of the Agile Coaches’ Corner. I am your host, Dan Neumann and thank you for joining us today. If you have a topic you’d like us to discuss, you can tweet it to us with the #AgileThoughtPodcast or you can email it to us at email@example.com. And before we get into the conversation on business value points with my colleague Adam Ulery today, I am obliged to remind you that these are the opinions of myself and Adam and not necessarily those of agile thought or other folks or other companies. So Adam, thanks for joining me today on this topic.
Adam Ulery: [00:49] Hi, thanks Dan. I’m excited to be here.
Dan Neumann: [00:51] All right, so business value points. What are they and why should we care?
Adam Ulery: [00:57] Business value points are a great way to help, uh, to help leaders measure progress against their investment, uh, for the product we’re building. So a lot of leaders or you know, sponsors, uh, funders of a project, one way to understand the progress teams are making towards building their product. A lot of times they’ll measure things they can see like velocity, but just measuring velocity alone is a poor practice. It can, we do a lot of dysfunctional behavior and it really only gives them a small part of the picture that they’re trying to understand. So we have found an effective way to give them a more complete picture. And it involves using something called business value points that I think we’ll dive into. And um, you know, we call this measuring business value.
Dan Neumann: [01:55] Right. So yeah, velocity is the much maligned tool of um, Scrum teams. You know, a lot of teams use them and it’s measuring the, the amount of product backlog that’s being delivered every sprint. It’s a way of, uh, a unitless relative size and right. It’s just one picture. It’s a pace at which the teams moving through the product backlog can be handy for forecasting. Um, and you’re saying the other, the other pieces missing then, the business value delivered.
Adam Ulery: [02:24] Right. And I think of it in terms of understanding the cost of something you’re buying. If you look at it from an investment point of view or, or the, the point of view of a person who is funding a project or a product to be built, they want to know how expensive it is to build pieces of that product. So in software they’d like to know how expensive features are and that can help them determine if the value they’ll get from it is worth building. And I think of it a lot like us shopping, pick your item. I like to talk about shopping for tools. So I go to the, to the store where they sell tools and uh, you know, if you tell me pick a drill, I’m going to go pick the most awesome drill I can find in the store. But if you say, Adam, you’ve got $200 to spend. Um, here is what you’ll be using the drill for. These are the types of projects you’ll use it for most of the time. That helps me a lot more pick something out that’s going to be right for the job. And I think this provides that capability.
Dan Neumann: [03:34] Adam, can you explain a little bit about business value points and what they’re measuring for? For those people who are trying to look at the progress and their investment.
Adam Ulery: [03:46] Sure. Business value points are measuring the amount of value a feature or story is expected to deliver to the business. And the business people are the ones who determine that. And so they’re, they’re estimating that a lot much in the same way a team would estimate the size of something, right? They’re saying, hey, this is my estimation of how much value this feature will provide to us.
Dan Neumann: [04:16] Yeah. So we’ve got teams, the people that are doing the delivery are estimating the product backlog items for their relative size, often captured in story points. And then you’ve got business stakeholders who are looking at the value of the product backlog items and um, relatively sizing those. So then you can effectively have a ratio of what’s the value, what’s the effort involved.
Adam Ulery: [04:40] Exactly. And that ratio helps tremendously with prioritization decisions. So when you’re centralized product owner or your product owner are looking to make prioritization decisions, they can look at that ratio and they can say, well, for how expensive this feature is, this is the value I’ll get. So if I’ve got two features that are the same cost, in other words, the team has sized them in the same as saying, yeah, this is the relative size of this feature. Uh, but one provides a lot higher business value than the other. Then it’s easy to see that. And a product owner can say, I’ll choose the one with the higher business value.
Dan Neumann: [05:23] And what’s been your experience related to capturing things that are maybe not directly tied to let’s say revenue. For revenues it’s easy, actually I don’t want to say it’s easy to measure, but we can look at a product backlog and say, hey, we expect we will generate “x” in terms of revenue coming in and there are other types of value that may be our cost avoidance. So if we do this, we won’t have to spend so much in labor. Or if we do this, we can save computing power or if we do this, we can retire another platform. How are you enabling conversations about about value beyond the revenue side of the equation?
Adam Ulery: [06:05] Yeah, that’s a good question. When we work with the stakeholders and the business people to teach them how to size things in business value points, we talk to them about using a combination of three things so they don’t just measure the revenue or the cost savings say as you’re asking about, right? So I like to compare this to teams who are familiar with sizing PBIs or user stories in story points, you typically factor in three things when you’re assigning a point value to an item, right? Complexity, uncertainty and effort. And based on the complexity, uncertainty and effort, you’ll arrive at a size. So if it’s an item that would otherwise be a five but you know little about it, you may bump that up to an eight. This is very similar. There are three components that I want business people thinking about when they’re sizing or putting business value on a feature or a story, user value, time criticality and risk reduction or opportunity enablement. So I can dive into the three of those. But I wanted to, to kind of let the listeners know there are three items that we ask them to factor in so they can determine a good well-rounded a piece of business value.
Dan Neumann: [07:37] Yeah, that makes sense. Right? We don’t want people just burrowing it on, you know, is it a revenue producing thing or not? Because then, you know, teams often struggle with this accumulation of technical debt in their backlog. Partly because there is not an obvious return on investment for retiring technical debt. You know, a lot of times folks get excited about new shiny features that users are going to look at and be like, wow, that’s an awesome feature. And that can lead to some very dangerous patterns in the software. Okay. So you said user value, time criticality and either risk reduction/opportunity enablement where the three facets
Adam Ulery: [08:15] Correct.
Dan Neumann: [08:17] Choose your poison. Which one do you want to go at first?
Adam Ulery: [08:19] All right, well we can just start with the top.
Dan Neumann: [08:21] It’s a good place to start.
Adam Ulery: [08:23] So you can call this user value, you can call it whatever you like, but it’s essentially what most people think of when they hear business value points, right? It’s the value of this feature to the business or to the end user. You can think about the end user of the software, what value will they get from it? So you may think in terms of the revenue it would generate, um, uh, uh, cost savings, you know, it’s more tangible type there.
Dan Neumann: [08:57] Okay. So something we can pretty easily, you know we can start looking at where the money is flowing. You know, are we, are we allowing the users to do something more effectively? Are we generating revenue or avoiding costs for the company? And that, that seems pretty obvious.
Adam Ulery: [09:11] Okay. So time criticality, uh, that is, think in terms of how important it is that you release the feature now for them to use, right? How important is it for the end user to use the feature right now? If it’s something that you want to get out right away because there’s a window in the market where we can receive great value from getting this feature into the hands of users, then that’s going to have a high time criticality. Uh, or if it’s one of those things where we could release it now we could release it in six months and the value of that feature would not change, then it’s a low time criticality. Makes Sense.
Dan Neumann: [09:57] It does. So a couple of examples that come to mind. If a company is doing something that they’re going to sell through retail, and it’s around the Thanksgiving holiday here in the u s so there’s the black Friday where if your product’s not in stores ahead of black Friday and you’re not able to get that massive bump in sales, it’s a significant cost. And actually, so cost of delay is, is another term I’ve heard used for what you’re describing,
Adam Ulery: [10:23] Right. That’s exactly right. Uh, okay. Another idea idea may be you’re trying to be the first to market with something and you’re racing against competitors, right? You really want to get that out there quickly.
Dan Neumann: [10:49] For our regulated folks who aren’t doing new shiny things that go out onto the shelves. If the auditors are coming in a couple months and you have to have an audit point from the previous year resolved or there’s a financial penalty that then would be a pretty steep cost of delay versus some other things that, like you said, maybe the cost of delay ramps up slowly or the, the time criticality isn’t as severe because there isn’t a big penalty for this week versus next week versus the month after the one after that. Okay. Yeah. So looking at that time criticality and having that drive, the business value.
Adam Ulery: [11:23] And then the last one is risk reduction or opportunity enablement. Um, this is, this may be the one that’s hardest for people to get their head around, but we’re talking about does doing this reduce the risk of a future delivery? Is there value in the information we will receive? Will, this unlock or enable new business opportunities in some way.
Dan Neumann: [11:49] For me, I think of this in traditional approach is a lot of times the risk get delayed. You know, we would test late so we have a risk until we test. We aren’t sure if the application’s going to scale and we test that at the end. So there’s a lot of of risk, um, increase in doing that and now it sounds like, hey, maybe we could, uh, look at how this might scale early on to reduce that risk. And so it’s really important to build a vertical slice, you know, through all the different layers. Maybe a particularly critical piece and find out if that scales well or find out if a user cares about this or remove a piece of technical debt that otherwise might bite us in the rear end later on.
Adam Ulery: [12:30] I think those are all really good examples, Dan. Another one that comes to mind or security, nonfunctional requirement type things, you know, um, or even tool or platform type things, right? That will, that will unlock business opportunities if we have a platform in place to, you know, provide a different set of features on for example, or something along those lines.
Dan Neumann: [12:58] Yeah. Things like, you know, with the, with cloud infrastructure being so available, there’s a lot of opportunity enablement that could be done by moving your platform into the cloud or moving your application into a cloud hosted environment before the flexibility. Uh, the resiliency, the uptime, what does security, whatever those cases might be. And those things, you know, your users probably aren’t going to see the move to the cloud. Uh, you don’t necessarily have to do it this month versus next year, but it does for a lot of folks create this opportunity enablement. And so I could see that as one of those factors. Um, one of those examples that opportunity enablement,
Adam Ulery: [13:36] Right. And practically how that’ll play out during a a sizing session is the, the business people who are doing the plan, the planning poker or however they’re sizing this or having those conversations, there’s probably a technical representative in there explaining to them the value of this from that perspective. And then that allows them to factor it in and from a business perspective, still give it that business value.
Dan Neumann: [14:06] That’s cool. So let’s talk a little bit about some of those, those practical points then. Who are the folks that you’ve seen be really critical in assigning business value or I shouldn’t say assigning, kind of determining it and identifying what it’s going to be.
Adam Ulery: [14:23] It is the business. The same way we like the people who are doing the work to be the ones who size the work. So, you know, having your development team size, the user stories, um, we like the business people who are receiving the value to be the ones who assign the business value to it. So business stakeholders, people in the business that um, you know, would receive value from this or would be able to assign a value to this.
Dan Neumann: [14:53] Yeah. And you’ve got a number of different perspectives there like you were alluding to. Somebody from the technology side, perhaps somebody maybe from the marketing side who’s representing the actual voices other stakeholders would be involved.
Adam Ulery: [15:07] Right. And I think it’s, you know, it’s going to vary a bit by organization, but the organization should determine who the right people to put this rating on the items are thinking from a business perspective. Right? And I, I want actual business representatives there. I don’t, I don’t want proxies who say, yes, I’m going to give it the value for them. This is what they would say. No, I want the real people who will be receiving the value to be the ones to write it. But just like when you’re having a story sizing session and you may have business people come in and give context to the team so that the team can appropriately size an item, you would do the reverse here where needed. You might have some technical folks come in and explain the, you know, why it’s important to be working on what feels like a technical item in terms that the business can understand and then the business can assign a business value based on that consultation.
Dan Neumann: [16:17] Yeah. If you are putting in place some characteristic of the software that’s going to allow the team to move at a multiple of the speed that it’s currently moving, that’s real value. You know most development teams are pretty expensive and so then if we’re allowing them to move more rapidly, more confidently, run experiments, whatever the, whatever the enablement is that they need, that’s tremendously valuable.
Adam Ulery: [16:42] Yeah. So during the conversation, when they’re sizing the items, putting that business value on the items, the business people will be asking questions that the technical folks can help them with and just give them the context and the information they need to make a good valuation on the item.
Dan Neumann: [17:00] Are you capturing all three numbers? Let’s say the, the user value, the time criticality and the opportunity enablement as three separate attributes. Are they kind of amalgamated into a single number to represent the um, kind of the total of them or, or some other, some other facets? So one number three numbers. None of the above?
Adam Ulery: [17:20] That’s a great question. It’s more the latter. It’s more the combination of the three. So I explain it as factor these into your size, think about them and allow them to factor into the size and it’s very much like dory sizing, factor in complexity, factor in uncertainty, factor in effort and then come up with a point value. Do the same here: factor user value, time criticality, risk reduction opportunity enablement and then come up with one value. And then these are relative, just like story points are to, you know, to size. These are relative measures. So we want a discussion. We’ll have the, the several business folks rating it and we want them to discuss and then come to an agreement on the final value. Make sense?
Dan Neumann: [18:19] It does make sense. No, it makes total sense. And then similar to size, you know, we’re going to refine the backlog periodically or progressive elaboration, whereas backlog items are bubbling up more towards the top. We’re going to periodically take an opportunity to refine those, elaborate them, break them down, maybe throw away some stuff that we just don’t want to do anymore. Uh, I would imagine that with user value points we’re going to do a, an analogous type of activity where, you know, as those, as the reality changes, maybe, maybe there is no longer value in doing some features. So we talked about the cost of delay increasing if it’s let’s say regulatory or some big market driver, but it could also becomes, there’s no value. Your value could plummet dramatically. Um, and there’s really no point in doing a piece of work anymore. So periodic reevaluation?
Adam Ulery: [19:12] Absolutely. I just consider it part of refinement. It’s very similar to the points on a story. Let’s refine these and as they change what’s update them.
Dan Neumann: [19:24] That’s cool. You’d mentioned one way of assigning the points through planning poker and we won’t do a deep dive on planning poker, but essentially everybody, there’s a brief conversation about the item and everybody’s expressing their opinion at the same time. And that’s an enabler for conversation.
Adam Ulery: [19:41] Yep. Yeah, that’s the preferred way to do it.
Dan Neumann: [19:45] And then another way, especially when you have a lot to do that, um, I’ve used it as a way to size a bunch of product backlog items is kind of card sorting where we, uh, we have a stack of those and we start to the first person effectively sizes one and the next one’s relative to the previous and so on. And we rapidly iterate through a pile. Have used similar techniques with story value yet?
Adam Ulery: [20:10] Yes, we use that as well. It’s a great way when you have a backlog that have no business value points on them at all to rapidly get an initial set on there. And it’s nice because then it gives the backlog some weight. Uh, so you can do as you explained and rapidly get business value points on the items in the backlog. Now part of your regular refining sessions, if you need to alter some of those as you go, that’s no problem.
Dan Neumann: [20:42] Okay. So today we’ve talked about business value, kind of a corollary to story points and you know, we’ve given a few practical tips, some of the “whys” to use them and some practical tips. And so we’d love to hear feedback from folks if they try using them or if there are some points they’d want some clarification on. As part of your continuous journey of improvement, what are you, uh, what are you reading Adam?
Adam Ulery: [21:05] Right now I’m reading a book called, “The Creature from Jekyll Island,” by G. Edward Griffin. It’s a, it’s a really mind blowing amazing book that explains our Federal Reserve system and how our banking system is rigged. I highly recommend it to anyone and everyone who has money of any kind.
Dan Neumann: [21:33] Yeah, that, that is interesting. I have not come across that one.
Adam Ulery: [21:40] I highly recommend it.
Dan Neumann: [21:42] Excellent. For me, I am reading a book called, “Nimble,” it’s off script but still on track, a coaching guide for responsive facilitation by Rebecca Sutherns, Phd and I’m really excited to share that Rebecca will be joining us for a podcast on the topic of facilitation and hopefully that will be rolling out here in just the next couple of weeks, so I look forward to sharing that. Well, thanks for joining today Adam, and we look forward to having you on again in the future.
Adam Ulery: [22:12] Alright, thanks for the opportunity Dan.
Outro: [22:17] This has been the Agile Coaches’ Corner Podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.