A Scientific Way to Prioritize Software Development Requirements

Requirement prioritization is one of the biggest challenges a software team faces. Actually, 25% of tech leaders said prioritizing software development is their biggest challenge.

So, we asked tech leaders about how they prioritize software development. It turns out there are many different ways a software development team can do it.

But one thing is sure:

Each requirement prioritization decision should be influenced by customer needs, always following business goals.

Among the many different prioritization methods, there was one method that stood out from the rest. It’s a sort of scientific, hypothesis-driven way to prioritize software development by Nick Zhu, who is the founder and chief tech guy at of Yroo.

This method works pretty well for their development team.

In this post, I show you how they use this requirement prioritization technique method for software development and help you to replicate it and apply this prioritization process to your team.

Applying this method requires a very discipline. team. You need to follow lean methodologies, break down your project into sprints and hold weekly and even daily meetings to make sure the project is on the right track and will be completed as planned.

Here is how to do it:

1. CREATE AN INTEGRATED ENVIRONMENT

As a tech leader, you need to make sure every engineer in your team isn’t just working on a list of tasks. They should have a clear understanding on the impact the task they’re working on has, seeing their direct contribution to the project.

They also need to be clear about the purpose of the product, not only understanding the customer's need but also the business’s value and goals.

via GIPHY

2. COLLECTING IDEAS FROM STAKEHOLDERS OF THE COMPANY

The best way to improve your product is to actively listen to your customers and collect their feedback and feature requests. 

This will result in a bunch of suggestions and ideas that need to be filtered. But one thing is sure: you’re one step closer to creating things your customers like and are willing to use or pay for. 

But not every request is equal. They need to be prioritized according to their potential business value.

Customers can provide valuable suggestions as well as the team members of the project.

There can be certain things like backend architecture that’s not visible for clients but for developers who can point to any architectural issues that could impact the product’s performance in the future.

This is why it’s so important to make sure every engineer in the team understands the product backwards and forwards.

Be open to different sources of suggestions, and do not underestimate the creativity of different unexpected sources.

3. TRANSFORM IDEAS INTO HYPOTHESES

via GIPHY

Once the suggestions/requests are collected, the next step is to transform them into hypotheses, making them measurable, comparable and eventually much easier to prioritize.

Creating hypotheses is also useful for avoiding confirmation biases; it sort of makes every decision more objective. You need to trust data instead of relying only on your gut and intuition. There is no ego, just data. 

The process should be pretty collaborative, letting anyone in the company contribute. During prioritization, you should consider the following aspects of every request/feature:

• Potential gains: What are the potential business or technical gains if the selected request is fulfilled? You could assign a business ($) value to each.
• How much effort it requires: Calculate the required man hours. If it seems complicated, try Planning Poker.
• Investment/return ratio: By calculating it, you will see the potential ROI on that request.
• How likely it could be true: We’re talking about hypotheses, which in some cases aren’t true. What is the likelihood that the gains and potential costs are right? This probability can then be applied to ROI to calculate probable return on each case.

4. GET READY TO PRIORITIZE SOFTWARE DEVELOPMENT REQUIREMENTS

via GIPHY

Bringing together every hypothesis with investment, potential return and probability makes it easy to determine the priorities.

Which idea has the highest investment return ratio with the highest probability of success?

From this, things are pretty straightforward.

Once you’ve selected the most important ones, put them into the backlog and when the time comes, schedule them into sprints.

Keep in mind that most of the experiments aren’t binary; some of them are neutral.

Always adapt to changing needs by actively listening to your customers and involving others from your company. You don’t know where the next big idea will come from.

CONCLUSION

Using this hypothesis-driven prioritization in software development requires a very disciplined team that’s hungry for trying and experimenting with new things. The better a team can select the most crucial requirements and prioritize those, the faster it will advance and move the business forward. Feel free to experiment with Nick’s process and let me know how it goes.