Story points and business value are related or not?

Story Points aren't related to business value. They tend to be on the side of difficulty, complexity, and necessary effort to complete the described work.

Ron Jeffries recently wrote a blog post that includes a brief history of points in Extreme Programming, which were adopted into other agile methods, like Scrum.

Story points (estimates) is not a measure of business value. But there is an automatic conversion that happens without our knowledge because the way we try to invest our money and time. More investment should yield better returns (ROI), but in software development this doesn’t hold true most of the times.  

Story points have no relationship with business value.  Ordering of the Product Backlog has more relevancy to business value than story points.  Points are a relative estimate size to other items. Size can be based on any number of data points and is going to be unique to every team. 

Value is measured by stakeholder satisfaction and the value of the work done to the business.  Again, value can be derived from any number of data points and can vary from PBI to PBI. Just like velocity shouldn't be compared across teams, value shouldn't be compared across PBIs.  Each one should be measured/interpreted individually. Then inspected to see if value is consistently being delivered and not how much value is delivered at any one time. 

Story points and business value are related or not?

Stories are one way of expressing items on a Product Backlog, story points being a means for their estimation. A story allows conversations to be had in which the value of such an item is clarified

Hence story points and business value ought to be related through the story itself. The Scrum Guide says: “Product Backlog items have the attributes of a description, order, estimate, and value.”

Hi  Ian Mitchell,

I would like to understand the concept more, Story points are for estimation & business value is for prioritization,

How can we consider business value while giving story points. 

I don't think business value is likely to be considered when estimating story points. Business value is one of many factors to be considered in Product Backlog ordering. Others include priority, dependencies, and potentially item size.

Hence there might be a relationship between size and value, in so far as a Product Owner may reasonably consider both (along with other things) when ordering the backlog. A small item of high value might be advanced to the top for example, given that the ROI is likely to be favorable.

Business Value need not be considered when estimating LOE for user stories. Business Value should definitely be a consideration when sprint planning.

As a Product Owner, I want the Dev Team to work on the user stories with the highest business value first, so my clients get more bang for the buck. (See, I just wrote a user story).

If you have 5 user stories totaling 75 story pts and a total BV of 50, I would rather you work on the 2 user stories I have that also have 75 story points but a BV of 80.

I'm going to go ahead and offer a dissenting opinion here. 



Yes, story points do not directly equate to value. They are made up numbers with no intrinsic meaning at all, just intended to help us get better data about the past so we can make better decisions in the moment. 



However, we're still prioritizing our backlog based on value. Whether something is big or small doesn't tell us where it should be in the backlog.



If the PO is doing what they should, and there are no other external pressures, then choosing to work on a larger item would generally only occur because it's a more valuable item. 



Therefore, you absolutely should be able to (in the abstract) equate points with value. In fact if you can't do that, it tells me we're using some very strange logic to decide what should be at the top of the backlog. 



If we've chosen to do an 8 point item over a 5 point item, the 8 point item SHOULD be more valuable, which means intrinsically that if all points are equal, 3 more points in some way means more value. 



This might sound obtuse, but I actually try to get teams thinking about it this way. Otherwise, we naturally start seeing numbers as time or effort measures, and success is 'doing more work'. 



By understanding that a bigger item SHOULD be more valuable, otherwise why work on it? This drives the right behaviour. 



Its something of an advanced topic, and I wouldn't generally start here, but once teams have gotten the basics of estimation down, I think this way of thinking is very powerful. 

It's been a few years since I last commented on this and I've changed my perception a little.

I will agree with you on this statement:

Yes, story points do not directly equate to value. They are made up numbers with no intrinsic meaning at all, just intended to help us get better data about the past so we can make better decisions in the moment. 

Since everyone has different concepts of what Story Points mean, there is no real way to provide a "universal" use for them.  The best that can be done is for an organization or team to provide a definition of what they mean and all people use that when dealing with Story Points.  But even in that model, each individual still has some freedom in the way they apply them so there is not a guarantee of consistency. 

Story Points are only useful for the team that is using them.  

Could a Story Point be equated to value?  Possibly, if the team using them has taken the value of the item into account when they provided their points. 

My personal stance and the one that I advocate is that a Story Point has no intrinsic value other than it being a guess at the complexity and effort based upon the information that you know today.  It is not used for any type of measurement.  It is solely used by Developers when pulling a set of Product Backlog Items into a Sprint Backlog to decide if they think the body of work is possible to be completed in the Sprint boundary.  Value is determined by the impact the item will have when delivered to the stakeholders.  Neither one of them can be adequately captured by a number because both of them are intrinsic in nature. 

I've often seen a focus on measures of velocity and story points when true business value isn't being measured or there is a lag in gathering customer facing metrics.

As you say, velocity, story points delivered, burns downs/up, cumulative flows and other team metrics are for the team to use to optimise their ways of working.

The organisation then needs to make an effort to identify what is valuable to the end customer and measure that. This will be things like sales, upgrades, cross-sells, visitors, session length, #bugs in live, #complaints and should also include qualitative things like customer satisfaction, organic traffic, promotion factor, etc. 

So there is a need for both and the organisation should focus on measuring what it wants to improve.

I also agree with many of the people who responded. Story Points are not related to business value. They are related to the assessment of difficulty, complexity and most importantly the effort required to accomplish the work described. That being said, business value can be combined with story points and should be an important factor in planning/prioritizing sprints. The combination of story points and business value should help the PO prioritize based on the value to be delivered to customers.

The way I have worked in the past is I would ask the stakeholders to define a value (from 1$ to 100$)  on each item so we could multiply the story point by the business value to understand the true value of a story. So for a 1 point story multiplied by a $10 business value is 10. But a 5 points story with a $1 value equals 5. So, we prioritized the story with 1 story point because it had a better business value.