22 September 2020
Do you want to develop software? Start with your business needs
Whether you are a Product Owner or Project Manager – business needs are important for you. From the Product Owner’s perspective, it’s something that makes you think about new software (or new functionality) and its shape, whilst for Project Manager – understanding business needs is crucial to write a good User Story. Thanks to that you can capture a description of a software feature from an end-user perspective. It must describe the type of user, what they want and why it is so. If you have business needs described in a straightforward way – most probably you will have no problems with creating good User Stories. Below, I present some advantages of well-prepared business needs.
I bet that anyone who worked in an Agile project probably had contact with User Story and describing requirements this way. For those who did not have the opportunity and for the forgetful, I will quote a formula:
As a < type of user >,
I want < some goal >,
so that < some reason >.
It is a very clear formula to describe the features that should be implemented. As a reminder of the rules, I will describe what this description consists of. In the first part, we take a user who will perform the action. Many of them can be listed when the same action will be performed by different types of users. In the next part – I want, we provide the action that the user will perform and should be implemented. And finally, the essence of our story: what are we doing this for? This is the most important element of the entire description because thanks to that we know what benefits the implementation of this functionality will bring.
The essence of the story I just mentioned is nothing else than the so-called business need. What is it? To put it simply, a business need is nothing more than the reason why a given solution is to be created. Michał Bartyzel in his article lists two main reasons that guide us when looking for solutions. The first is the benefit we get from doing this. The second is the problem we want to avoid.
Why is knowing the needs so important for our project or even task? If the client tells us about the benefits that they will achieve thanks to this solution, they tell us how they will measure the success of our activities. It’s good when they know what they expect and what the final result should be. Our task now is to create a solution that will achieve this result.
In the second case, when the client tells us about the problems they are struggling with in the current system, our task is to find out the source of the problem. Of course, you can always suggest shortcuts and “patch up” the problem, but it’s not that we really want. And here we come to the core of our work at the initial stage of the project, but also at the later stages.
Getting to know the business needs will help us in building the right thing.
That is, in creating a solution needed by users. After all, we build systems and products for them, so that they can use them and be satisfied with it. That is why it is so important to know the expectations of our users. It is not an easy task, but there are many techniques that can help us discover our needs.
5 whys method
One of the techniques we can use to prepare it is the so-called “5 whys”. Anyone who has children may have already encountered this technique in a natural environment (with way more than just five whys being asked repeatedly, but you know the drill 😁). Usually, 5 questions of this type are enough to get to the source of the problem. A good example would be the following:
- “Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.
- “Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
- “Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
- “Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
- “Why is the intake clogged with metal shavings?”Because there is no filter on the pump.
Please note that we do not end with question 5 if we feel we have not yet reached the root of our problem.
Another thing is to make a summary of this series of questions. Going back to the example given above, such a summary would be:
What do you think? Is “NO FILTER ON THE PUMP” a root cause?
See also: How to write good User Stories in Jira?
5 whys can be used in individual conversations with our end users too. Of course, this is not the only technique that can be used to discover Product Owner’s needs. Nevertheless, it is quite simple to learn. If there are many stakeholders involved in the project, and even more so when they come from different departments/groups, then it is worth using workshop methods. Their advantage is gathering more people in one place and clashing the needs of different stakeholder groups, and even the visions about the project or product, against one another.
Very often, it turns out that in one area of the company, the view on the implemented project may be radically different, but thanks to workshops we can make this vision consistent and discover the real needs to be implemented. There are also many workshop techniques and they depend on the purpose of a given meeting, the group of people involved and how much they know about the project. The result of each such work should be the development of business needs and requirements, as well as the definition of the scope of work and final results.
Understanding the business need is the most important element of each project as well as individual tasks. Thanks to that, we know what we want to achieve and what the end result of our work should be. Thanks to the business need, we can also prioritize the workload and its order more easily. You should not strictly stick to the arrangements from the initial stage of the project, but react to the newly emerging needs arising from the market or from real users. It is worth having a person in the project team as well as on the client’s side, people who will ask about the business justification of the emerging requirements, because thanks to this we will build things that are needed by users.
- Mohamed Elgendy – http://mohamedelgendy.com/blog/business-needs-vs-requirements.html
Additional bibliography (in Polish)
- Michał Bartyzel – https://www.michalbartyzel.pl/czym-jest-potrzeba-biznesowa/
- Białko – https://bialko.eu/agile/potrzeba-biznesowa/