Story points and business value are related or not?

Last post 10:40 am May 27, 2022
by Jack Leon
10 replies
Author
Messages
09:17 pm June 6, 2019

PO maximizes value delivered to end user by working collaboratively with the development team but (in my opinion)  story points used to deliver feature (or story) may or may not closely related to the business value delivered.

Story points/velocity help development team to plan their work and to have better delivery predictability. On other hand, business value is what delivered to end customer and how they recieved it. Feedback from customer is good measure to know the value delivered.  Delivered feature may or may not have same value for customer when compare to how many story points taken to develop that feature.

Other point, Story points may vary from team to team within organization based on approach team taken for feature/story implementation and how team understands its complexity but business value delivered will not change based on which/how team perceived that feature/story.

Please share your thoughts on this.

09:39 pm June 6, 2019

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.

01:43 pm June 7, 2019

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.  

03:45 pm June 7, 2019

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. 

04:33 am June 8, 2019

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.”

10:31 am December 14, 2020

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. 

10:14 pm December 14, 2020

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.

05:33 pm May 20, 2022

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.

08:08 am May 26, 2022

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. 

02:56 pm May 26, 2022

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. 

10:40 am May 27, 2022

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.