What is the next story/task/epic to do? How many of you face this on a daily basis? come on, let’s be honest — most of us. Tools such as Jira ‘help’ this somewhat with their ‘priority’ and ‘severity’ fields, but developers often find it a struggle to prioritize stories based on those two fields alone. This short article hopefully details an approach that is more understandable to developers and other stakeholders.
Background
Way back before software development became a thing, there was a technique attributed to a famous WW2 General and American President called the Dwight D. Eisenhower and is now called “The Eisenhower’s Matrix”.
The Eisenhower matrix is a 2x2 Matrix technique where work and are tasks are placed in one of four boxes:
- Important and Urgent.
- Important but Not Urgent.
- Not Important but Urgent.
- Not Important and Not Urgent.
The technique works … but for software development, it can be hard to map User and Customer stories into the right box in the matrix.
Another common technique is the ‘Rice Model’. This is a scoring model which helps prioritize tasks based on a number of factors. These factors include ‘effort’, ‘impact’, and ‘confidence to implement as part of the calculation. The basic formula is:
RICE Score = (Reach x Impact x Confidence) / Effort
We feel that the ‘confidence’ and ‘effort’ variables are vital in prioritization. If something takes a lot of effort, then it would be obvious to try to split the story into simpler sub-tasks where you would have a better understanding of what is needed. The more clarity in a story, the easier it is to prioritize and implement.
The problem we have with the RICE model is that most examples and descriptions within a software agile framework tend to relate to the common view that ‘reach’ and ‘impact’ are given in relation to ‘Customers’. As a developer we know the customer is ‘king’, but we also know that this is not the whole story. There is this whole area known as ‘infrastructure’, ‘support’, and other non-customer stories. Yes, you could argue that they are kind of ‘customers’ — but it sits uncomfortably with most developers, ourselves included, who feel that view is somewhat contrived.
Customers and Companies
After many years, we came to the conclusion that ‘infrastructure’ and ‘support’ stores were generally written from the wrong perspective. Where previously we would have written:
“As a manager, I would like to know how many widgets of type ‘X’ were bought last week.”
or
“As a developer, we need to use Kubernetes to help to scale customer demand.”
or
“As a support engineer, I need information in the logs to enable me to debug customer issues”
These are in reality examples of ‘bad’ stories. Stories need a business rationale and can be framed from a company and a customer perspective. What it took us a while to understand is that a company is a ‘legal entity’ — just like a person. A company can be sued in court, sue others in court, be held liable, and has legal responsibilities. The stories above should have been written as:
“As a company, we need to record the number of individual products sold and in what category within pre-defined date periods so that we can analyze them and base business decisions on this information.”
and
“As a customer and a company, we expect that a performant and functional sales system is available 24x7 with a 99% availability level, which can automatically handle peaks in customer demand and is responsive to that demand and cost levels set by the company.”
and
“As a company, we would like information about our systems and applications to be available to developers, customers and support staff, amongst others — at a sufficient level to meet their needs and no further.
All information needs to be detailed and rich enough to cater to multiple needs without being too verbose or insufficient in nature.”
OK, having said that — how does that apply to prioritization?
The Riomhaire Prioritization Technique
Essentially the technique (and this is something which can be added to JIRA, or spreadsheets - however you do your project planning) is a variation of the RICE model and has the formula:
Riomhaire Score = ( CustomerImpact x CompanyImpact x Confidence) / Effort
CustomerImpact has positive even scores in the range of 2 to 10. A reason for this is that customer stories of the same ‘size’ as company ones should have more value. Customer is what is ultimately important right?
CompanyImpact has positive odd scores in the range of 1 to 9.
You will note that both of these are greater than zero to ensure cancelling does not happen.
Confidence Is a tricky one. We tend to use ‘1’ for not confident at all, ‘2’ for ‘probably will make it’, and ‘4’ for ‘confident’ to make it to production.
Effort Is another tricky one. We use Fibonacci values: 1,2,3,5,8,13,21,34. That said anything more than an 8 indicates we need to break things down.
OK, we have a formula and value range - so let’s Prioritize!
Taking the three stories mentioned above:
- Product Sales.
- System Availability.
- Information Availability (aka ’logging’)
Let’s apply the scores from a developer, product owner, and a customer to the above:
| Story | Customer Value | Company Value | Developer Confidence | Developer Effort | Score |
|---|---|---|---|---|---|
| Product Sales | average(2,4,6) | average(9,9,1) | 4 | 5 | |
| System Availability | average(10,8,8) | average(9,9,7) | 4 | 13 | |
| Information Availability | average(2,2,2) | average(6,6,4) | 2 | 3 |
Which is with rounding:
| Story | Customer Value | Company Value | Developer Confidence | Developer Effort | Score |
|---|---|---|---|---|---|
| Product Sales | 4 | 6 | 4 | 5 | 19 |
| System Availability | 9 | 8 | 4 | 13 | 22 |
| Information Availability | 2 | 5 | 2 | 3 | 6 |
The one with the highest score is the most important — and should be done next
Based on the above … ‘System Availability’ would be the highest priority followed by ‘product sales’ and then ‘Information Availability’. A bit contrived for sure, but we hope you understand where we are coming from.
Riomhaire Prioritization Taking into Account of Dependencies
There is a variation of the above technique which we use pretty much as standard — especially where multiple teams are involved and where team A will have a dependency on team B for some feature. We all know dependency management is a pain. Sometimes an upstream team wants to develop a feature that is dependent on a team that does not have that feature as a priority — if at all. At this point managers usually get involved and some serious ‘haggling’ is involved. A better approach is to get the downstream team to prioritize their part of the story (with input from the various interested parties) and add that as a dependency. The formula to use is:
Riomhaire DScore = (1 + dependencies x -1) x Riomhaire Score
So let’s say in the above example two of the stories have no dependencies, but the ‘System Availability’ has two dependencies - Management sign-off of the cost, and the Infrastructure team setting up the necessary systems. This would therefore be mapped to:
| Story | Score | Dependencies | DScore |
|---|---|---|---|
| Product Sales | 19 | 0 | (1+0*-1)*19 = 19 |
| System Availability | 22 | 2 | (1+2*-1)*22 = -22 |
| Information Availability | 8 | 0 | (1+0*-1)*6 = 6 |
This means ‘System Availability’ would not be worked upon until sign-off by management and infrastructure has been achieved.
We hope this short piece on Prioritization and Customer vs Company has been useful. As with anything software development-related, this is very much a ‘work in progress.
Stay Safe.