Linkedin Twitter
ARTICLE

Understanding Business Value

BY: Flt.Lt. M. Sridhar Chakravarthi  

It was a regular Tuesday of a routine week. After taking care of the routine activities and a few daily stand ups, a few of the scrum masters and Agile coaches joined for a quick lunch. After the typical cribbing about the unreasonable POs and customers, the discussion went into the prioritization based on business value. It became a serios discussion. 

Everyone started providing their perspective. Some people said that business value is defined by the effort we spent. Others said that it was defined by the customer business impact. A few expressed that it was captured by the story points as we were anyway calculating them. The discussion became inconclusive, and everyone left for their post lunch meetings and tasks. That discussion started a thread of thinking and I started researching about the customer value from basics of marketing. This article is the result of those deliberations.

Everyone wants to maximise business value while delivering their projects. But what is this business value? How can we measure this?

Can we equate no. of features to value?

This won’t work. In most of the cases, the bulk of the product features are basic in nature, which are expected as default by the customers. These are not perceived as major value adds as every other product would be offering them. As they are not perceived as differentiators, they don’t generate additional business and hence their business value is low. It is like the chassis of a car which is mandatory but the customer neither sees it nor considers it as a differentiator.


Can we equate efforts to value?

Not directly. We can’t say that we have spent a lot of efforts building the core features and hence they are the most valuable. The amount of effort spent is also a function of the team capabilities. A novice team may spend a lot of time building the basic features compared to an expert team who would build them quickly. That way, the more time we take to build the basics, the less valuable the team is.


What is this business value? 

Any product will have three levels of benefits – core benefits, good to have and aspirational benefits. Core benefits are the basic functionality any product is expected to have without which it is deemed useless. A pen must be able to write first. All other bells and whistles are additional, which will be appreciated only if the pen writes smoothly. Good to have features are those additional things which improve the customer experience of using the product. A watch built into the pen could be one such feature. Then comes the aspirational features, there are the features which make the product stand out, differentiate the product in the market and appeal to the customers. These are the wow factors customers talk about on the social media. These are the features which sell. 

However, the good to have and aspirational features can only sell if the core functionality is working well. This is the way, customer perceive value. It is akin to constructing a multi-storied home where the customer is excited about the indoor swimming pool on the third floor and the roof top garden and is willing to pay top dollar for them. However, they won’t matter if the foundation is not strong, and the first two floors are functional. What we need to understand here is that we can’t forget about good to have features and go directly to the wow factors. In a competitive market, the customer expectations are ever evolving. The good to have features become core features and marquee features will be considered good to have. This is a continuous evolution of the product driven by ever increasing customer expectations.  

In such a situation, where should we spend more money and effort? Obviously, it makes more sense to put the efforts in the features which are wow factors and differentiators in the market. 

Please refer to the diagram below. 

We should be spending only 20% of efforts on 60% of features which typically add 20% value. An additional 30% of efforts can be allocated to 25% of the features, which deliver 30% of value. The remaining 50% of the efforts can be dedicated to 15% of the features which deliver 50% of the value. These values are an approximation and can vary based on the product context.


How can we do this?

We must reduce the effort we spend on building the core features through reuse and automation so that we can spend more time in building the new marquee features. We may even acquire the base product and build additional features on that, if such a product is available in the market which can be white labelled. The new marquee features would probably need more R&D and spikes in the sprints which are a must to ensure quality product. The level of expertise and skills required for these three groups of features would also vary and we can deploy the resources accordingly, with better efficiency and utilization. 


Can we prioritize the high value features first in the sprint?

It depends. If these features can run independently, without the core features, we can consider releasing them as a separate app. If they can run only on the core features, then they must follow core features in the priority list. In this scenario spending less time and money on the core makes sense. 


What are the possible conflicts here?

The first and foremost conflict is the value assigned to 60% of the core features. While the team will have to build and deliver this, the business does not attribute a lot of value. This can make the team feel undervalued. The solution for this is coaching the team in the concept of business value and make them realize that they should stop looking at value from their perspective, in terms of effort spent.

The second major conflict that can happen is when the customer starts pushing the team to deliver the marquee features quickly, as only 15% of them are remaining. Here there is a possibility of customer trying to calculate the feature wise effort spent or trying to convert story points into efforts; and expect a similar effort to be sufficient for the marquee features as well. This can put the team under tremendous delivery pressure, effecting the morale and quality of the deliverables. In this scenario, the customer must be taken into confidence in the beginning of the project and the development strategy should be agreed upon. The need to spend 50% of the effort on marquee features must be understood and agreed by all parties. 

The third possible conflict can happen when the core features are completed, and the marquee features can be prioritized and taken up for development. There could be a tendency to relegate the good to have features for later builds and expedite the marquee features. As we have already discussed, we can’t sacrifice the good to have features as the customers are already expecting them to be there.  Hence, the only way to manage this conflict is to reduce the time and effort from a conventional approach and complete them fast, to ensure that we have enough time for the marquee features.    

In summary, figuring these things out up front can bring a lot of clarity to the Scrum teams as well as the customers. The product would be delivered more efficiently and can also have lower time to market. 

 

Flt.Lt. M. Sridhar Chakravarthi is a seasoned business leader with 30+ years of versatile experience. He is a Certified SAFe Scrum Master and a Certified Agile Coach. 

He has trained and coached more than 500 IT engineers and managers in Agile Methodology and related frameworks. He strongly supports Enterprise Agility and believes that business agility can happen only when the teams develop an agile mindset. He lives in Bengaluru, India and loves long distance bicycling and writing.