A Helpful Framework for Prioritising Development Work

Part of the Prioritisation Series

Photo by Kvalifik on Unsplash

Preamble

Recently I conducted a comprehensive review of my professional work since graduation. A product of the review was that I had a great number of case studies to interrogate and discover how good decision-making could be systematised and bad ideas could be rejected at the earliest possible stage.

This article is my attempt to summarise and share the resulting framework with you. It covers how to prioritise work, with a focus on the product management of software.

Key Performance Indicators (KPIs)

Prioritisation is all about achieving your goals, the goals of your department and the goals of your company (yes in that order). Your first task is to list them and know them by heart.

Evaluating a Problem

For the purpose of this series, I define a problem as an issue that requires development work. The first step for prioritisation is to eliminate any non-problems; this can be done by scrutinising the underlying assumptions behind issues that are presented to you.

Non-problems are those supported by untested assumptions. For example assuming that you cannot negotiate with a supplier and must immediately start work on adapting to their new terms, or assuming that customers would appreciate a given feature without even talking to them.

If a genuine problem has been presented, it must be prioritised, this should be done according to the impact it will have on the business (severity) and the time constraints acting on the window of opportunity (urgency).

Top priority: X marks the intersection between severity and urgency

Priority should be assigned at the intersection between these two axes, with the highest priority afforded to solving problems in the top left of the table.

Further explanation on and details on evaluating a problem can be found here.

Evaluating Solutions

Now that you have a problem and have prioritised it accordingly, you need one or more solutions.

The first stage is to create a standardized checklist (like the one found on tab “6. Screening each proposed solution” of this Google sheet). Use the checklist to weed out any solutions that are obviously bad or don’t improve your KPIs. The checklist will also help you quantify how much time the project will take, and flag up difficult aspects of the project.

Solutions are supposed to solve problems but they also consume resources, therefore they can be evaluated for comparison on two axes:

1. How difficult they are to build, and;
2. how elegantly they solve the problem.

Difficulty is a measure of the time (and therefore resources) it takes to deliver a given solution, and elegance is how well a given solution solves the problem. The categories of difficulty and elegance should be rigidly defined and consistently enforced to enable accurate comparison between solutions.

Now you can plot your solutions at the intersection of their respective categories of difficulty and elegance:

Comparing Solutions Based on Their Intersection Between Difficulty and Elegance

It is generally best to opt for the solution to the problem which sits nearest to the top left of the grid and reject the others. I have added points to each intersection to indicate visibly when there would be a rough equivalence between solutions (the lower the points the better the solution).

More detail on this section as well as the methodology for estimating difficulty and elegance are contained in this article.

How to Prioritise

Evaluating the problem has shown you:

• how important the problem is.

Evaluating the available solutions has given you:

• the tools to pick a solution (or solutions) that will best solve the problem, and;
• an objective estimate of the resources (especially time) that will be required to deliver that solution.

Given these insights you should now:

1. pick the best solutions,
2. prioritise them by how important it is to solve their problem, and then;
3. schedule adequate time and resources for their development.

Practical Benefits

In a practical sense this means that we can:

1. Reject work that has no value (or at least have a much higher chance of doing so).
2. Assign work (for sprints) in a way that uses a developer’s time most effectively.
3. Manage the expectations of management with regard to delivery schedules.
4. Present logical and reasoned arguments for why we chose a given option when challenged.
5. Improve on this system and get better faster.

This was a short summary please see my articles on evaluating problems and solutions if you are interested to know more.