Real boundaries in agile

Agile tips: the Priority Pyramid

Tomas Rybing
Colour pyramid image via Shutterstock

Are you looking to improve the way you’re prioritising work in your agile environment? Tomas Rybing presents the ‘Priority Pyramid’ which has resulted in positive feedback from the wider Kanban community.

My name is Tomas Rybing and I’m an agileist.

What is an agileist? It’s the words ‘agile’ and ‘idealist’ put together. With agile I mean software development methods like Scrum and Kanban that are based in Lean, where solutions evolve through collaboration between self-organizing and (sometimes) cross-functional teams. Agile promotes adaptive planning, evolutionary development, early delivery and continuous improvements.

An idealist is a person that has high ambitions and strives towards a greater goal, they ”aim for the stars” and act upon that goal.

Back in 2008 Corey Ladas (the author of ”Scrumban”) came up with the brilliant “Priority Filter“. It felt really good when I first read about it. But it could be something more, even more “visible”. I came to think of a pyramid. With this concept in mind I contacted Corey.


With this blessing from the inventor of the “Priority Filter” I felt confident to continue.

The Priority Pyramid

What is the extra value that the pyramid adds? It gives hard boundaries that truly highlights the priority. Given the size of your pyramid and the stickies that you are using, there is a physical limit how many that can fit inside! You can use the Priority Pyramid as a visualized backlog.


The Priority Pyramid is divided into the following sections:

  • Priority One (P1) – At the top of the pyramid, with the highest priority. This is for ongoing tasks
  • Priority Two (P2) – In the middle of the pyramid. This is for tasks that will be started as soon as resources become available
  • Priority Three (P3) – At the bottom of the pyramid. This is for tasks that will be worked on soon
  • Rest of backlog – Below the pyramid the rest of the backlog is written. At this stage the tasks can be written directly on the whiteboard, or be lines on a printed list

Also seen in the picture above is the WIP-limits (Work-in-Process limitations). Basically it is a limitation for how many tasks that can be present in the section at the same time. Looking at the example above it’s the figures within parentheses (i.e., 1, 2 & 4). Use an increasing sequence n x 2 for each underlying section in the pyramid. Starting with 5 at the top will give WIP-limits of 5, 10, 20, I think you get the hang of it.

Tasks flow from the bottom of the Priority Pyramid and upwards, as the arrow to the left of the picture indicates. When a task is completed it is moved to a “Done”-area outside of the pyramid.

How to operate the Priority Pyramid

Looking at the picture above with the Priority Pyramid, let’s assume that the yellow sticky in P1 is completed and moved to Done. Now a business decision needs to be made. Shall the green or yellow sticky in P2 be started (and moved to P1)?

Since we haven’t made any premature decisions about priority, but instead waited until the very moment it’s needed, we usually have all the information at hand to make the best decision possible. Let’s say that the green sticky represents the most important task right now and it’s moved to P1. This is the only business commitment we make.

Now we make two more decisions, that are without commitment (i.e., can be changed later). We move a P3 task to P2, let’s say the red sticky. And we write a new sticky for an upcoming task from the backlog list. Next time a task in P1 is completed we repeat this procedure. This might feel cumbersome, and it’s true that you don’t want to have too small tasks (in terms of work effort needed). User stories represent a reasonable size of work effort.

Below is an example of a Priority Pyramid in full swing.


After my initial blog post, here are some comments from the Kanban community about the Priority Pyramid:


This blog post originally appeared on The Agileist, Tomas Rybing’s blog about Lean, Agile and Management.

Tomas Rybing
Tomas lives in Stockholm, Sweden and has been working in IT since 1996, starting as a consultant and programmer. From 2007 his focus has switched to team leading, project leading, product management and development methods. He's a big fan of penguins and pyramids.

Inline Feedbacks
View all comments