Many agile teams have become obsessed with speed. How fast can we release? How fast can we close stories? How fast can we deliver to market? What too few fail to realize, however, is that none of this speed matters unless what the team is delivering is actually providing value to their organization.
But how do you measure the value that your team is delivering? One of the most common methods of measuring value is by assigning business value points to the stories in your product backlog. These points can be assigned at the sole discretion of the product manager or may be arrived at in conjunction with the delivery team, via a collaborative exercise such as the Business Value Game.
But why take the time to assign business value points to your stories in the first place? There can actually be many advantages of assigning a business value to the items that your team is working on.
One such advantage is that assigning a quantitative business value allows you to subjectively track the amount of business value that your team is generating each iteration. You can easily do this by creating a business value burn up chart that tracks your team’s accumulated business value each iteration, or even by adding an additional series representing business value to your team’s existing release burn up chart.
A release burn up chart that tracks the complexity points a team has completed each iteration as well as the resulting business value that team has delivered. Note that even though the team has continued to deliver strong through iteration 8, their resulting business value has plateaued since iteration 6 resulting in the organization receiving diminishing returns from the team. Hmm…
But another, perhaps more important, benefit of assigning business value to each of your team’s stories is that doing so allows you to better understand how the business value each story is expected to yield relates to the expected complexity of that story. Often times, we assume that those stories in our backlog with a high estimated complexity are also those stories which are likely to yield the greatest value. However, this isn’t always the case. By tracking the estimated complexity of each story you can more easily spot cases where the expected business value of a story doesn’t seem to align with its estimated complexity, such as instances where a story is estimated to be very complex but yield comparatively little business value.
By identifying discrepancies between a story’s complexity and the expected value that it’s likely to yield, you can begin to consider options for splitting that story in a way that maximizes the value your organization receives in return for your team’s effort. When doing so, you’ll find that many stories can be split into smaller components upon closer inspection.
For example, imagine that you’re the product manager for an ecommerce app. Your app currently accepts credit card payments via a third party payment gateway for two of the most common credit card vendors in your target market. However, your customers have also asked for support for additional cards, as well.
In response, you’ve added a story to your product backlog which adds support for 3 of the additional credit cards your customers have requested. Since your app already supports the most common credit cards, you assign a fairly low business value estimate to it. However, once your team estimates this story you’re shocked to learn that the complexity of this story is significantly higher than you expected.
But rather than simply discarding the story you decide to ask your team for more details. In doing so, you learn that the two of the new credit cards you’ve chosen are actually supported by your current third-party payment gateway. Therefore adding support for these cards is simply a matter of enabling them in the current gateway.
However, the third credit card is actually a bit more obscure and is not supported by your team’s current payment gateway. They have found another gateway that supports this card, but adding support for it will result in integrating an entirely new payment gateway as well as updating the app’s architecture to support switching between multiple gateways depending on the credit card the customer chooses. Armed with this new information, you’re able to split this story into separate smaller stories for each additional credit card, adding support for the first two credit cards immediately and deferring support for the third, more obscure card, to a later date. As a result, you’ve maximized the value that your organization will receive from their investment into your team.
However, despite all of the benefits that assigning business value to stories can bring, there are a few pitfalls that can befall this practice.
The first such pitfall is forgetting that regardless of how these estimates are arrived at, estimated business value is always subjective. Remember that there’s no greater way to validate your product than market acceptance. For this reason, while estimated business value is an important data point, it’s no more than a single data point in your planning.
Another pitfall is that while business value can be assigned to a story of any size, it tends to provide the most benefit when it’s applied to larger stories. In general, we want our stories to be small as working with smaller stories comes with many natural benefits. Smaller stories tend to carry less risk, they can be delivered quickly, and are easier for your team to understand and work with. But the smaller your stories become the more difficult it can be to quantify their expected business value. This results in a perverse incentive to make your stories larger so their business value can be more easily quantified while increasing the complexity and difficulty of delivering that story for your team.
This means that while you can assign business value to stories of any size, you’re likely to find that this practice yields the most benefit when used at the epic or feature level. In fact, a great use of this practice is to estimate the business value that’s likely to be gained by each feature you’re considering for an upcoming release during your normal release planning process. In doing so, you can best plan for how your team can deliver the most value to your organization in that release.
We often conflate the business value a story might yield with the complexity involved in delivering that story. But a story’s resultant business value, and the effort required to deliver that value, may not be necessarily related.
However, by explicitly considering the potential business value of each feature that you work on, you’ll be better positioned to maximize the value that your team can deliver to your organization and your customers.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
