With countless requests and limited resources, effective prioritization becomes crucial. But not every method steers us in the right direction. Some might focus on quick wins, while others aim for lasting impact. In this article, I’ll go through the essentials of prioritization and give you some qualitative methods, with special focus in its applicability in an Agile environment.
Definition of Prioritization
In project management, prioritization is the process of determining the sequence in which tasks should be tackled based on their significance, urgency, or other relevant criteria. This ensures the most vital tasks are addressed first, optimizing resource allocation, especially when they are limited.
Through effective prioritization, teams can achieve critical objectives on time, manage stakeholder expectations, and enhance the chances of project success. Prioritization is critical in Agile as it helps ensure that the team is always working on the most valuable tasks at any given time.
Now, let’s go through some methods that you can use to prioritize your work, no matter if it’s a to-do list, the product backlog, or even a project portfolio.
HiPPO: Priorities based on opinions instead of data
Deciding where to focus energy and resources requires more than just intuition; it demands a structured approach. However, organizations often fall into the trap of the HiPPO (Highest Paid Person’s Opinion) where decisions lean heavily on seniority rather than objective data. Such a practice can lead to skewed and volatile priorities. For instance, a company, influenced by a HiPPO, might divert resources to develop a feature seen as innovative by a top executive, only to realize later that their target audience finds little value in it. This misalignment, rooted in preference over data, can result in wasted effort and missed opportunities.
To avoid the HiPPO pitfall, encourage a culture of data-driven decision-making and ensure diverse input from all team levels in discussions and evaluations. Use dashboards to make it transparent to everyone and, if you cannot avoid it, I suggest you label those requests and assign explicit policies to manage them (e.g. use a specific swimlane in your kanban board). This is how you can show the impact of these requests on the rest of your work, so you can stop working on the urgent and work on the important instead. This is, by the way, the foundation of Eisenhower’s matrix.
Eisenhower Matrix: Urgent vs important
The Eisenhower Matrix gets its name from Dwight D. Eisenhower, a former U.S. President. Think of it as a map to help you figure out what to tackle first.
It’s a 2x2 matrix split into tasks you need to do right now (urgent) and tasks that matter a lot (important). Here’s how you fill them out:
- Urgent and important: These are your now-tasks. Do them right away.
- Important, but not urgent: Plan these out. They matter, but there’s no rush.
- Urgent but not that important: See if someone else can do these. Pass them on if you can.
- Neither urgent nor important: Either skip these or do them when you’ve got some free time.
The great thing about this method? It’s super straightforward. You can see right away what needs your attention. While it’s a bit like other methods, like picking out the most critical problems first (like in a medical triage) or the MoSCoW method, the Eisenhower Matrix is all about quick visuals and easy choices. But unfortunately, life is more complicated than that.
MoSCoW: How to manage expectations
The MoSCoW method is actually a variant of the Eisenhower Matrix. It consists of classifying tasks into these possible classes:
- Must have: For those tasks that cannot be avoided.
- Should have: Being able to distinguish between something that cannot be avoided from something that can it’s very valuable in some organizations.
- Could have: This is probably the most useful class, because it offers the possibility of postponing those tasks and it opens the door for using an iterative and incremental thinking.
- Won’t have: You can also use “Wish” instead of “Will not”. In practice, it’s a polite way to say No without saying No.
This is a pretty effective method, especially if you do it collaboratively with your entire team and the main stakeholders of your product, because you are sharing a lot of information and giving the opportunity to understand (and manage) everyone’s expectations. I frequently use this method during User Story Mapping workshops. For teams unfamiliar with iterative and incremental planning or those overwhelmed by a big number of features to prioritize, I propose using MoSCoW to create the first slices of our plan.
The key benefit of MoSCoW and similar methods is that they allow us to compare between features. Given the constraints on resources, particularly time for development, these methods compel decision-making. As a facilitator, it simplifies the process to ask “If it comes to a point where you can’t develop these two features simultaneously, which one do you prefer MORE?”. This is a very powerful question and the answer is usually very easy with the right people in the room.
Something similar happens during the exercise called “The not list” in the Agile Inception Deck. It is a variety of the medical triage I referenced earlier, and helps for a first discard of ideas that should not be part of the scope of the product or project. This is, more or less, the same that we are doing with MoSCoW when the number of features is too big. The goal is always to minimize, with the least effort, the cognitive load so we can focus on the most relevant features.
Impact-Effort Matrix
You are probably familiar with the expression “quick wins” when looking for small features bringing high value. Then you have already used the impact-effort matrix. This is probably the best known scoring method to prioritize work. It’s a 2x2 matrix that classifies tasks as:
- Low Impact - High Effort: We shouldn’t be working on such tasks as they are resource drainers.
- Low Impact - Low Effort: Consider for downtime as they are nice-to-have features.
- High Impact - High Effort: Big bet. It requires strategic planning.
- High Impact - Low Effort: Quick-win or low-hanging fruit. We should start with these ones.
You are probably seeing some coincidences with the MoSCoW categories (I’ve coloured them intentionally to emphasize them), but there’s a notable difference.
At the Impact-Effort Matrix, we use two scalar axes (impact and effort), allowing features to be assigned a specific value, such as low or high. The crucial aspect is reaching a consensus on the definitions of “low” or “high” for impact and effort. As you implement this method, the benefits become clear: it fosters alignment on prioritization criteria. Moreover, it sets the stage for strategic discussions about your product or project, empowering the team and involving them in decision-making.
The strength of this method lies in its perceived simplicity. However, in practice, determining the exact parameters for high or low impact and effort isn’t straightforward. Often, it initiates teams’ efforts to estimate the work required for a feature. This is something that I already discussed in another article about estimations. But, at this stage, pinpoint accuracy in estimates shouldn’t be expected.
For instance, defining “low effort” as taking a few days and “high effort” as spanning several months is sufficient. Similarly, for impact, a “low” could equate to minor monetary gains, while “high” might mean a lot of money. For such broad estimations to be effective, managers must comprehensively grasp both the technical challenges and business opportunities at play. This is why it’s so important to assign the values together with the team.
In the next article…
All these methods work fine when the number of tasks or initiatives is low and manageable by a few people. We need methods that scale and give a better sense of objectivity. We’ll see methods based on scoring formulas and the powerful concept of Cost of Delay.
