prioritization framework PLAN

PLAN – A Task Prioritization Framework

Swift pre-sorting of backlog items

In product management and software development, getting the tasks’ priorities right is half the battle won. For faster planning of what to work on with the teams, I created my own pragmatic task pre-sorting & prioritization framework. I call it “PLAN”.

The Long List

The common practice in some teams I work with is to allow and even encourage every member to create GPS tickets for new tasks, ideas, or technical issues. While this is great for transparency and inclusivity, the downside is that these tickets usually land at the bottom of an already long backlog.

Over time, the backlog becomes a daunting list, stretching longer and longer with each passing day. Sifting through this behemoth list becomes time-consuming when the planning phase rolls around.

The lack of structure in the backlog doesn’t just make planning tedious. It also takes the fun out of it. Seeing the list grow with no clear way to manage it efficiently is disheartening. It’s like watching a pile of laundry grow; the larger it gets, the less you want to tackle it.

Furthermore, the responsibility of organizing this list often lands on my shoulders, which is neither enjoyable nor a productive use of my time. I craved a lightweight, semi-automated process to pre-sort the backlog, saving me time and the headache of manually organizing it.

The PLAN Method

When I started to think about how to pre-sort and pre-prioritize potential tasks swiftly, I found the simplicity of the MoSCoW method and the Eisenhower matrix appealing. MoSCoW divides tasks into Must-haves, Should-haves, Could-haves, and Won’t-haves, while the Eisenhower matrix categorizes tasks based on urgency and importance.

These two methods make sense and can be generally used for prioritization. However, they didn’t mesh 100% with my pragmatic, highly async remote work environment.

First, MoSCoW’s categories aren’t a perfect match for our daily issues (well, and the acronym is confusing). Second, the Eisenhower 2×2 matrix ideally requires a visual representation, which isn’t ideal for quick prioritization on the fly without a whiteboard and a meeting.

So, after playing around with these two methods for a while, I came up with the PLAN method:

PLAN Prioritization Method

PLAN is an acronym for:

  • P: PRESSING: The urgent, critical tasks.
  • L: LISTED: Important (not urgent) tasks to consider in the planning.
  • A: AD-HOC: The nice-to-haves or quick wins.
  • N: NEUTRAL: Tasks that aren’t urgent at the moment and can wait.

All you need to experiment with this concept are four buckets in your project management tool. In Jira, for example, it’s easy to set up these additional sprints in the backlog. You can simply name them PRESSING, LISTED, AD-HOC, and NEUTRAL.

So now, when anyone creates a new ticket, it directly goes into one of these four buckets. Your team members can also do this, i.e., not just you as a PM or PO. Sure, it assumes everyone has a decent understanding of the general product direction. But this should be the case anyway.

Note: Although these buckets naturally have an implicit priority, I consider this activity a pre-sorting only. It gives a better overview of the rough nature of the tasks. Based on that, you can more easily decide on the final priority later on during planning sessions.

The PLAN method isn’t about achieving perfection but having a little more clarity and sufficient organization. In particular, it’s far easier now to immediately differentiate between a LISTED task and an AD-HOC task. It can be tiring to figure out when everything is mixed up in one extensive list.

Meditation App Example

To make it more tangible, let’s look at some examples I’ve made up for a meditation app:

PRESSING

  1. Addressing a critical bug that prevents users from accessing the meditation library.
  2. Resolving issues with payment processing that hinder users from subscribing.
  3. Managing unexpected server downtime affecting the app’s availability.

LISTED

  1. Adding a new feature like a breathing exercise module.
  2. Improving the app’s loading speed and responsiveness.
  3. Updating the user interface based on user feedback for better user experience.

AD-HOC

  1. Incorporating new meditation soundtracks based on recent trends or user suggestions.
  2. Enabling users to share their meditation statistics on social media.
  3. Adding a quick tips section to help users make the most out of the app.

NEUTRAL

  1. Adding support for additional languages.
  2. Developing a dark mode feature for the app.
  3. Planning for a community forum where users can share experiences and tips.

Good Enough

The PLAN framework is not a miracle solution, but it’s practical and works well most of the time. The quick pre-sorting provides a clearer view of the tasks, eliminating the struggle of sifting through a jumbled backlog.

You would typically balance these four buckets when picking from there during planning. How you do that in detail depends on many variables unique to your organization. In the end, you want to maximize the value for your customers while having an eye on individual efforts, etc. And which tasks to combine or tackle first can be challenging to decide. But at least the PLAN pre-sorting gives you a better starting point for that often tricky activity.

So, if you are unhappy with your backlog situation, try prioritization with PLAN. It’s only a simple tweak, and it’s good fun to see some structure emerging with almost no added effort.