An overwhelmingly large backlog can be a challenging thing to manage. To get it under control a “prioritization framework” may be the solution.

One option is declaring “backlog bankruptcy” and scrapping the entire thing to start from scratch. This can be popular if many of the items are old, a new team has taken over a project, or you just want “a new start”.

Another option is to take control of your backlog and put features in a priority order for execution. A “prioritization framework” may also be the solution for backlogs that have a large number of stakeholders vying for work from limited resources. Either way, a system would help evaluate each work item and produce a prioritized list of work.

PIE Framework 🥧

One framework to help is PIE (commonly defined as “Potential”, “Importance”, and .“Ease”). This framework allows for each feature to be evaluated by three different criteria, totalling in a “PIE score”. Scoring for each criteria would ideally be numeric values 1-3, 1-5, or 1-10 where the final score (sum of the three criteria) for a feature provides a suggestion to the items’ overall/backlog priority.

  • Potential: What could the lift be on this update, project, or experiment? Could the update increase subscribers / users / monthly active users?
  • Importance: Will the feature have high visibility / traffic? Is the update needed at a specific date (supporting a conference)? Is this an ask from leadership?
  • Ease: How complex is the update?

When an item scores high on “potential”, “importance”, and “ease” it is a no-brainer to take on. Features on the other end of the spectrum should be placed at the bottom of the backlog.

Scoring

The idea of the criteria scoring is to maintain consistently but not be formulaic. Defining a formula that spans all work items is too challenging and it’s near impossible to define something that will accurately represent all types of work.

Providing hypothetical or historical examples for the various levels within a criteria will help keep the scoring grounded and relative.

Choosing the right numerical value can be challenging. Starting with a simple 1-3 (“low”, “medium”, and “high”) is a good start. The more granular the scoring becomes, the better the results, but the more difficult the criteria definitions become. For example, when using a 1-10 score for each criteria, differentiating a “5” from a “6” becomes much more challenging.

Maintain the spirit of PIE

Depending on context and existing nomenclature, changing the names of the PIE values may help it land with the team and be better understood. For example, “importance” could be replaced with “priority”, or “ease” could be replaced with “simplicity”.

The important part is that the meaning of these criteria doesn’t change. Altering PIE to allow for scores to be provided based on “role” or “type of stakeholder” is not recommended. For example, purposing PIE to mean “engineering team” vs “program management team” vs “ease” is not an ideal approach to a prioritization framework. The criteria should be universal to the team executing on them and “priority” should not be dependent of role.

The real value

The real value of the PIE framework is the documented business justification. The numerical values that come out of the exercise are secondary to having the “potential”, “importance”, and “ease” documented within a feature.

Providing a numeric value for a feature helps, but it’s still subjective. An engineer filling out PIE values may not be exposed to business needs at the same level as business analyst, program manager (PM), or CEO. If anything, the PIE Framework should be used as the vehicle to document business justification and ease.

Not the end-all

As alluded to above, a prioritization framework shouldn’t be the end-all solution to prioritization of work. It is a framework that provides input into a human-driven exercise. Having PIE values filled out at the beginning of a stack-ranking meeting or backlog review is extremely valuable, but it’s still ultimately up to us humans to figure out the order in which work gets completed. Expecting a prioritization framework to work as a machine where “item with inputs goes in, stack-ranked items come out” is not the reality of collaborative prioritization. However, providing high-level anticipated lift to the business, prioritization justification, and engineering considerations suggesting ease is extremely valuable for priority conversations.