How to identify the business value of individual features?

A simple answer to the questions: Will this functionality be worth it? Is it of such value? Is it worth investing in it?


Šimon Macháň

Product manager


At the time of working from home and various other adjustments to the operation of companies due to the situation associated with COVID-19, we at MobileSoft decided to invest more time into our internal projects. After all, they are something that we enjoy and where we gain an incredible amount of experience, which we can then apply to other projects.

This way we are able to provide our customers with added value like few others in the market. We are forced to address what normally would be "client questions" ourselves. We need to determine if a specific function (feature) is going to be worth the investment. Does it add that much value? Is it worth spending the resources on it?

Trying to enhance our performance in this respect, we tried a new form assessing the business value of individual functions within our AppBlock team. How did we go about it you ask?

First, it was necessary to "harvest" ideas. People inside and outside the team spew out ideas about what they would like to see in the application. We then input everything into Jira as stories (but any spreadsheet would do the same job). For all these ideas we created individual tasks, or instructions (rough outlines of what the given function or feature should do, what it would look like within the app, etc.) When this was done, we assessed how demanding each of the ideas would be to implement using Story points. More complex functions were split into smaller parts for easier categorizing.

After assessing how difficult each feature would be to implement, we held a special meeting with the whole team and the stakeholder or "client" – our boss Míra. All features were discussed to the extent that there were no further questions. We listed them all on a whiteboard but obviously without their Story point values because what were after was determining the FUNCTION VALUES without taking into account the complexity of implementation! 

Everyone was given a certain number of poker chips and after introducing all the features, it was game time: everyone distributed their chips among the cards – the higher the chip value, the higher the value for the application. When all the chips had been placed (none could be left), all individual members of the team were asked about how many chips they assigned to which card and why. We then noted down the values for each feature and added them up.

This gave us the column "VALUE", and then there was nothing left but a discussion between the team members whether it all corresponds to reality and possibly some slight convincing that this and that is really worth it, etc. :-) However, an agreement was reached quite smoothly. Finally, we simply threw in the "DIFFICULTY" column which represented an assessment of how demanding the implementation would be that we had prepared in advance.

By diving "VALUE" by "DIFFICULTY", you get a number that defines Business Value. Visually you can express it for example using the following diagram:

I use this drawing very often, both for myself, to keep in mind that one needs to stick to development according to BV, and of course to explain this reality to newcomers or clients. It is always simply a matter of the best possible ratio – you want for as little effort (or "money") to get as much value as possible (also "money"). And that's the whole trick!


These are things that the client often does not quite see and using his or her ego attempts to push functionality that definitely does not bring high BV. It is up to us as a partner in the development of the application to explain it to the client and preferably to sit down together (the team and the stakeholder/client) and do exactly what I described above. We did this with AppBlock and I think it was greatly beneficial. However, it’s the numbers that matter so we'll see soon whether or not we had gone for the right features!