Reevaluating Value – Why Is Value So  Important in Product Development?

In this article, we’re going to learn why business value is important when it comes to developing a business idea, overall product development and finally Scrum processes.

Value in Scrum is closely related to what we consider to be the most important metric for assessing actions – ROI, which is short for “return of investment”.

Keep reading to find out how it all comes together.

Business Value              

Every time we have to make a business decision, we need to pre check if there is value in pursuing that goal. 

By checking our idea one at a time if it will solve an actual need of our users, eventually we’ll identify an idea that is worth pursuing and then build a product that has value for the user. Without it, we won’t have a useful product. 

The ideal situation is to conduct a research and develop real metrics of a business, of what business adds to end users. 

Go out and talk to your customers. Use their problems as a starting point for your business idea. Potential customers are a valuable resource for figuring out in what direction your idea should go. Use meetings, talk to them over the phone, create surveys, be direct. 

Based on that feedback, you will be able to figure out the initial business value and whether it makes sense to pursue it.

A SWOT analysis for example, which examines market opportunities, threats, strengths and potential weaknesses, can be a very effective type of research.

Without validating business value before starting the development of the product we will never have users who will use the product. That’s how important it is. 

Now we know what business value is and why it’s so important but how to deliver it?

Delivery of Business Value

Okay, we did the research, talked to end consumers, and discovered that our product is needed. In other words, we are confident  that our idea will add value. What next?

If we’re talking about the entire product, we should create an MVP and ask our clients if they really need it. This will spare us some priceless time and money and prevent us from going into the wrong direction.

Similar steps must be taken if we are creating a new feature: create the basic version, then release it. The comments we receive from our clients will help us determine whether it is useful to them and whether there is room for further development.

This is the crucial move when it comes to agile methodology – to test out what you can on the market until your final product is really adding value to your end users. This is also the difference between Agile and Waterfall methodologies. 

But what additional differences exist?

Delivery of Value in Agile vs. Waterfall

What is the difference between Agile and Waterfall methodologies in terms of handling value? The crucial difference is its earlier delivery of value and a quicker feedback cycle allowing us to reevaluate our idea in time and pivot towards something that will maximize value delivery.

In Waterfall, we have a linear delivery of the product. We go from phase to phase in developing a product without turning back and tweaking some steps. Here, the value is delivered in the end, which is why you are not able to evaluate the product before it gets to the market. 

On the other hand, in the Agile approach, you have what is called an incremental delivery. As a development team, you are always delivering value as soon as possible. This means adding incremental chunks of value one at a time. 

The Agile Triangle

However, the transition from traditional to agile work organization is not always smooth. This leads me to the iron triangle of project management. 

Because all events were time-boxed, the traditional triangle (scope, schedule, and cost) was centered on scope as a fixed value. 

On the other hand, early development of agile project management was focused on schedule as a fixed value.

Lastly, The Agile triangle, which represents a true agile project management framework consists of value (to the customer), quality (continued value to the customer) and constraints (scope, schedule and cost).  

So the key emphasis in Agile is on always looking how to deliver maximum value and quality within the given constraints, while in Waterfall is delivering the agreed scope and following through with plans, making compromises as we go.

Great advantage that Agile gives you is an opportunity to reevaluate the value your product brings to the end user. Remember Friedrich Nietzsche? He was totally for revaluation of western values, christianity, and wearing a huge mustache. 

If our current product is not valuable, working inside Agile methodology will help you to adapt and modify or completely abandon your idea (Nietzshe didn’t abandon the idea of his huge mustache though, but was still quite agile in thinking).

Difference between Waterfall and Agile is in the ability to adapt. With Waterfall, you’re not able to reconfigure your system, go back a few steps, etc. With Agile, you can always reevaluate things and work based on that. Work backwards, freeze processes, focus on something else.

The crucial thing in Agile is the value. We are always focusing on producing it incrementally and  delivering (in the end) the highest possible value. Let’s go over incremental delivery now, before another Nietzsche reference comes to mind.

Incremental Delivery Concept

When it comes to incremental delivery, there are three crucial things: Faster delivery, revaluation (omg, Nietzsche again) and highest value.

Incremental delivery gives us the value faster through its iterative stages. We don’t have to wait for the full product to be completed, to see a certain feature that we already developed, like in the Waterfall methodology. After every cycle, we are able to examine the product incrementally and reevaluate it as needed.

That way, when the final product gets to the market, we have already made sure that it has the needed value for end customers. This leads me to the next point.

Since we are always evaluating the rest of our ideas and adapting the development towards the highest value that we can deliver in the next increment, we are able to achieve the highest possible value at the moment.

On the other hand, since we are adding value incrementally, meaning, we are always adding the highest value at each stage, the final product is of highest value. 

How to do all that in a Scrum like process?

Sprint Goals

Ok, we know what incremental delivery means in terms of value. Where does it all fit in Scrum?

Sprint goal is where we define the biggest value at a particular moment. At the end of the sprint, the biggest value is delivered through product increment. We take all tasks, user stories, etc and create a spring goal that represents the biggest value. 

For example, we have a running app with a couple of features that we want to develop. However, there are bugs which are preventing users from using our app. A sprint goal can be to fix all the bugs since it’s an urgent issue, and therefore, the highest value at the moment. 

We want to solve this problem and remove these bugs and allow our users to use the app without issues. At that point, this is the biggest value because without fixing the bugs, our application is not that useful to end users. 

Creating additional features will not bring that much value since user’s won’t be able to use them. After we fix these bugs, we can evaluate again and see what is our next highest value. 

We can determine that developing these features are the next highest value and add it as the next sprint goal.

Incremental means that work is added to the existing product and delivered to the end user at the end of the sprint. Each product increment needs to satisfy the Definition of Done. Without it we can’t be sure we have a working product increment and thus, we can’t be sure we are actually delivering value.

So you want to keep adding features to your product incrementally that will bring the highest value to the end user, but at the same time, you need to estimate effort/cost for developing that feature. You don’t want to develop a product that will take you ages to make (or do you? What are you, a God?).

ROI as a Metric

Finally, we can get to the crux of the matter! ROI is the only valid metric for deciding on each step. It needs to be the metric of our business decisions. Each decision should be quantified in terms of ROI. 

The way you determine if its worth pursuing your idea is represented in the following formula:

 Predicted value

———————— = ROI 

     effort/cost

Keep in mind that “predicted value” and “effort/cost”s can be expressed using any metric as long as they are applied consistently across contexts and are thus comparable.

After you calculate ROI, you’re going to be able to decide on your next action. Calculating ROI for different potential ideas can save you time and money, since you’ll always choose the option with the higher ROI.

Value and ROI in Scrum Process

Finally (Vol.2), we can understand why value is so important in Scrum. Although ROI cannot be predicted with absolute certainty, we can make educated estimates, and it is a very useful decision factor. In Scrum, you can (and should) use ROI for prioritizing tasks. Before each sprint, we need to predict ROI for each task. 

For instance, suppose you want to add a restaurant menu feature for a meal ordering app. We anticipate that this functionality will provide significant value to the end customer. During the planning phase for the development of this feature, the development team estimates the effort. 

Based on what we assume would be a reasonable effort and the tremendous value that this feature provides, the ROI will be large, thus it makes sense to prioritize it.

On the other hand, creating a facial recognition feature that can automatically recommend food options to end users based on skin condition, requires a huge effort while providing a lot of value, which is why, in the end, it has lower ROI. 

What then?

Ok, we estimated ROI for each task and then selected the tasks with the highest ROI to be included in our sprint. Those tasks will then form the product increment.

As we know, the product owner defines the initial value for each task and the development team estimates the tasks/effort. 

If we apply the same formula from the previous chapter, the initial value and the estimated effort are taken (estimated by the development team) and ROI is estimated for each user story. Based on those numbers, the product owner should prioritize tasks in a way that I previously described

This process is repeated continuously, and different priorities are always in play.

Based on these prioritizations, we know that the team is producing the highest value at all times. Why? Because after each iteration, we have another prioritization. Let’s see another  example:

We want to develop 3 features. We create the first one. After initial feedback, we learn that feature 2 needs to be modified to add enough value to end users and feature 3 is redundant since its functionalities are already covered in feature 1 and 2. 

We proceed in the second iteration (second sprint) with only one goal (highest estimated ROI among others), to modify feature 2. The end result is two features (maximum value/maximum estimated ROI) instead of 3 features (one not optimal and one redundant).  

The Bottom Line

You’ve reached the end of this article and luckily learned why value is so important. The main thing is to always focus on the highest value, by using ROI as the most important metric. 

Break down your tasks and figure out which one is more important. Your team will give you estimates and you prioritize based on ROI.

If everything goes according to plan, you just might have a competitive product that is useful for end users. With that in mind, I leave you to your calculations.