Ever since the industry started adopting incremental deliveries instead of the waterfall approach, making sure the product delivers the most valuable features at the right moment has become more critical: 45% of IT companies suffer cost overruns due to unclear objectives, lack of business focus, unrealistic schedules and reactive planning. Assuming we have a solid time and cost estimation, the first question that arises is: What should we do first?
We’ve previously published an in-depth guide on prioritisation methods.
Here’s your TL;DR version with an epic cheat sheet to download!
First off: What does it mean to prioritise?
For our purposes, the prioritisation process is defined as a requirements triage: The process of choosing the right requirements that satisfy a set of criteria that should be included in the next release of your product.
A priority is a ranking attribute of a requirement or task that results from a prioritisation process.
What should I avoid?
Prioritising by business value only
- May block valuable features
- Can create unnecessary technical debt
Rule of thumb / prioritisation by guts
- Creates biased results and removes the objective mathematical layer that a good engineering process provides.
- Biased results provoke a lack of trust amongst the team and risks creating false expectations in the stakeholders.
What method should I use?
First of all, ask yourself the question:
Is it a small or low risk project or a big or high risk project?
For smaller projects, use some simple but powerful methods to help you:
- Ranking by business value and technical impact
- MoSCoW method
- 100 Points / $100 method
For big or high risk projects, we need more analytical options that can help us avoid ambiguity and subjectivity. That’s why my default choice is to prioritise by value, cost & risk, one of the top-ranked methods for prioritisation.
Let’s look at each of the above in a little more detail:
Small or Low Risk Projects
Ranking by business value and technical impact
The basic idea here is to prioritise your task by assigning a qualitative score (high, medium or low) to the business value and technical impact (complexity):
Pros
* Simple
* Takes both technical and business perspectives into account
Cons
* Repetitive values in big projects
* Hard to coordinate all stakeholders to choose a value
* Not clear if both criteria have the same weight
* Ambiguous and limited for big project
MoSCoW method
MoSCoW is an acronym for the four possible priority classifications of requirements that we Must, Should, Could or Won’t perform.
Pros
* Simple
* Takes both technical and business perspectives into account
Cons
* Repetitive values in big projects
* Hard to coordinate all stakeholders to choose a value
* Not clear if both criteria have the same weight
* Ambiguous and limited for big projects
100 Points / $100 method
Each team member gets a budget of $100 and needs to decide which features they want to spend it on. In order to consider the technical complexity, it is possible to assign the required effort to achieve a specific feature as the cost. That means that more complex features have higher costs.
Pros
* Simple
* Forces the team members to rank and “throw the garbage away”
Cons
* Intangible assets could represent more value or enable other features and a money-based method could be harmful.
* People could negotiate their money and create alliances that benefit participants’ particular interests instead of considering the real business value.
* Risk of someone allocating all the money into a specific task
Big or High Risk Projects: Prioritisation by value, cost & risk (Wiegers and Betty Method)
This method prioritises based on the relative business value that a feature, user story or functional requirement will provide to your business, the relative cost or effort of implementing a specific feature and the risk or probability of not getting the feature right the first time.
Note: The business value is defined as the sum of the relative benefit that a specific feature will provide to the customer or business and the relative penalty that the customer or business will suffer if a specific feature is not included.
Pros
* Reduces ambiguity & subjectivity
* Provides an accurate priority
* Extensible & can be adapted to our needs & constraints
Cons
* Simple, but could be an overkill in small projects or quick prioritisation
* In agile environments, it’s difficult to bring in all perspectives from business stakeholders
Click on the image below to download the epic cheat sheet:
This article was written by Juan Urrego - Software and solutions architect with thorough hands-on experience of software engineering, software architecture and agile development. He has entrepreneur, IT consulting and university lecturer experience with high emphasis and interest in AI and machine learning.
