Software development exists, in the end, to solve Business problems and bring as much Business value as possible. If our role is the one of "Business Analyst" in a software company, we feel not meeting our goals if we are not able to identify the real Business needs and if we are not able to prove the Business value delivered by the applications or features to be developed.
Is it enough to have a number set as "Business value" for each user story? Should we also be aware of the real Business value behind that number? Would this help us and our teams provide the best possible solution and do things right from the very beginning?
For the Business Analysts in the product companies, this article might not open any discussion, because they know their customers, they have direct access to their customers and they are always thinking of creative techniques to prove the Business value of the products or features they and their teams can deliver.
For the Business Analysts not living in this "perfect world", proving the Business value of the features to be delivered is still a big challenge. I choose to take on this challenge.
Is it enough to have a number set as "Business value" for each user story? Should we also be aware of the real Business value behind that number? Would this help us and our teams provide the best possible solution and do things right from the very beginning?
Let us imagine the following scenario: the Business value is "quantified" in some number on a specific feature and our task is to give the best possible solution within an existing system. The ideal (or maybe, normal) situation is when we know the Business goals behind our customer's requests.
I will further refer to the "not so ideal" or "not so normal" situations…
The question that most annoys our customers (and it also annoyed me when I was the customer) is: "Why do you need this?". When I was the customer, I got annoyed by this question because I thought I knew why I needed a certain feature better than the ones asking the questions. I knew what the Business value of that feature was. I did not think I should give any explanation to the service provider.
In my current role (on the service provider's side), I can really understand why we need to know the answer to this question. I try not to get the customer annoyed, by replacing the question "Why do you need this?" with the question: "What is the Business value this feature would bring to you?". The main purpose of this question is to understand the Business value behind a request, so that we can give a solution that makes both the team and the customer happy.
The answers to the question: "What is the Business value this feature would bring to you?" do not only help the Business Analyst, but the entire team and the customer.
These answers help the customers by clarifying if they really need what they requested. They help the team by making everyone excited that the best solution is delivered, that they started right and that they are going in the right direction so that they can build the right thing. These answers are the first ones to challenge us to think of the best solutions.
In my opinion, no matter on which side we are, by being aware of and by starting with the Business goals in mind, we can provide better solutions to our customers and, in the end, bring the best possible value to the Business. In this way, we can deeply understand what "hides" behind our customer's requests.
Most of the times, the Business Analyst is the first one to challenge back customer's requests. There is no recipe to do this and it depends a lot on the project context, the customer's profile and many other aspects. But we could start by searching for "the Why" and by always asking: "What is the Business value this feature would bring to you?". It is never too late to ask this question.
We could continue by clarifying the Business goals of our customer and defining (or redefining) the features to be developed with these goals in mind.
We could then split these features into smaller requests and map them onto the Business goals we initially identified. We could then set Business value numbers on these requests and measure the real Business impact our solutions could bring.
This article is meant to raise awareness and open discussions. Depending on each project context and customer profile, different solutions, techniques or methods could be used. If you are one of the Business Analysts still struggling to challenge back, I would like it if we could all share some ideas on this topic. How do you prove the Business value of the features you and your team deliver? How much do you challenge back?
by Iulia Bicu
by Vlad Vesa
