There are three common scenarios that generate prioritization decisions outside of an individual or team’s span of control.


The second category of prioritization problems is risk tolerance mismatches. This category focuses on how organizations and teams balance the exposure of having people and resources in the wrong place or accepting work that fails to meet expectations. The process of work entry and prioritization matches the value and the risk of a piece of work to the needs of an organization. Every organization has a risk profile. Some organizations chase projects with very uncertain outcomes for high rewards.  SpaceX and Blue Origin are examples.  In the same industry, United Launch Alliance is far more risk-averse. The risk profile of the organization will impact the projects each firm takes. Accepting work that is outside of the risk tolerance yields stress and increases the likelihood of work that either does not meet the expected return or outright failure. Leading these types of projects can also be career limiting.  Three leading causes of mismatches are:


Prioritization is a topic as old as time. Jon M Quigley pointed me at old Spanish and German sayings about prioritization.  The one that struck me was:

“Who grasps at too much loses everything” (unknown)

In today’s world, losing everything translates into higher technical debt, defects, or problem tickets. None of which sound quite the same, but are all painful. One chronic area that generates prioritization problems is timing. Here are some examples: 

Too long of a planning horizon. Prioritization often requires a lot of time and effort which means prioritization becomes an event held at major calendar demarcations (annual, semi-annual, or quarterly — these are often driven by reporting and financial needs). The real world is usually more dynamic, which means people prioritize work outside of the major events using less rigorous approaches. Long planning horizons can generate other bad practices including:

  1. Urgent work is being prioritized over important work. The person that is yelling the loudest commands attention. The classic Eisenhower Box is useful as a framework to sort through how urgent and important a piece of work is. Importance should trump urgency – easily said, but hard to do without an approach.
  2. Queue jumping. The longer the time between prioritization sessions, the harder it is to assure stakeholders that their needs will be addressed on time. This creates an incentive for stakeholders to try to get someone to start on their work outside of normal channels. Queue jumping disrupts the flow of work and makes EVERYTHING later than it should be.
  3. Team level priority drift. Teams prioritize on a more finite schedule which means they can drift away from the top priority without the involvement of their product owners (or whoever is playing that role – someone always is).

Too short of a planning horizon interacting with a longer work cycle. Continual reprioritization which leads to changes in direction or starting or stopping work at any level is demoralizing or is at odds with rules or principles of iteration-based methods. For example, Scrum resists changing priorities at a team level during a sprint.  Short time horizons lead to anti-patterns including:

  1. Re-prioritization fatigue – Teams get tired of being redirected and either strike out on their own (facilitating queue jumping) or ignore changes in priorities. This is a leadership issue; nip either problem in the bud.
  2. Turnover – Demoralized team members leave or create toxic work environments. Ensuring that there is a match between the planning/prioritization cadence and how teams and groups work is not an esoteric discussion. Mismatches can have huge impacts in the way throwing a pebble in a pond causes ripples that seem to go on forever.

The nursery rhyme about the three bears provides a good metaphor for too-long and too-short scenarios; the goal is to match work cycles, business dynamics, and organizational requirements (not too hot, not too cold, but getting it just right). One solution is to understand what part of the organization needs to have an asynchronous approach to prioritization is value stream mapping.  A value stream is a set of activities that are intended to create and deliver a consistent set of deliverables that are of value to customers.

Next: Risk tolerance mismatches — a people and process problem.

Deciding which work to do when is critical in any job and at all levels of the organization. Messing prioritization up leads to waste which can impact both the organization’s top and bottom lines. If the process worked perfectly there would never be any question about what a team should be doing today or tomorrow. Unfortunately, nothing in life is quite that simple or straightforward, especially when people are involved.  Prioritization doesn’t always work for a variety of reasons.  These reasons can be grouped into five categories.


We continue to explore how prioritization techniques can change over the life cycle of a product. Using a simple product life cycle it is easy to recognize the different strategies embraced by product managers and owners. When a product is new, the goal is to establish a competitive advantage and to develop distance from its rivals. Prioritization methods such as, cost of delay and weighted shortest job first can be used to identify features that can get to market quickly, matching the product strategy. In the growth and maturity phases, models such as Kano expose the distinction between features that excite and those that satisfy. The feature mix is a function of which strategy is being pursued. For example, overweighting new features during growth will be useful, however as the product matures more and more legacy functionality needs to be maintained. Maintenance costs increase as more and more legacy functionality is accumulated leading to an inevitable decline. Prioritization, at this stage, leverages impact on crucial clients and/or cash flow to determine what to fix. This why ticketing systems exist and become the primary source of requirements for older products. As products decline revitalization projects/programs are often undertaken in an attempt to resurrect the product — a true cycle akin to rivers in the natural world. So-called next-generation products attempt to shift a product back into the growth phase which requires prioritization techniques again.   (more…)

In earlier entries, we described several approaches to prioritizing work. One of the questions that emerges when discussing prioritization is whether the same technique should be used for all types of applications. The simple answer is no, however, a bit of context is needed. One determinant of approach is where a product is on its life cycle. Note: I am using the term product very purposefully, product and project life cycles reflect two very different concepts.  The illustration below is a common representation of a product life cycle. The product is introduced, stuff happens, and then, at some point, it is retired. Whether the journey emulates a normal curve or follows a different path is not material here.  (more…)

Do not walk on the dunes sign

WSJF can’t go everywhere!

On March 10, 2015, I wrote an entry on Weighted Shortest Job First (WSJF), in a nutshell,  WSJF allows you to prioritize units of work using the lean concept of cost of delay and duration/time to complete. The approach provides a consistent framework for prioritization. This is my favorite of the advanced quantitative approaches. Instead of rehashing an old article (go back and read it before continuing), we will examine a few of the pros and cons of this approach. (more…)

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 577 features our essay on approaches to backlog prioritization. Today we will share some background and a simple approach because sometimes a straightforward approach will fit the bill!

Also this week, Susan Parente joins the cast with an installment of her Not a Scrumdamentalist column.  Susan discusses agile myths.

Re-Read Saturday News

In this week’s installment of our re-read of Thinking, Fast and Slow we talk about risk policies. The concept of risk policies dovetails quite nicely with our discussion of story and portfolio prioritization.   

Remember, if you do not have a favorite, dog-eared copy of Thinking, Fast and Slow, please buy a copy.  Using the links in this blog entry helps support the blog and its alter-ego, The Software Process and Measurement Cast. Buy a copy on Amazon,  It’s time to get reading!

The current installment of Re-read Saturday:

Week 31: Chapter 31: Risk Policies 


SPaMCAST 578 features the return of Evan Leybourn.  Evan and I discussed HR Guilds and news from the Business Agility Institute. 

Aldi's Nuts

Count the nuts!

Quantitative prioritization focuses on counting “things” such as money, new customers, or market share. This form of prioritization has one basic requirement, whoever is prioritizing work needs to agree on at least one tangible attribute that can be identified and counted.  A classic simple approach to quantitative prioritization uses Return of Investment (ROI).  ROI is defined as: (more…)

Large switch

Requirements are more than just on or off!

The Kano Model is a tool to help categorize product requirements.  The model created by Professor Kano groups all requirements into five categories:

  1. Must-be Quality, also known as basic needs,
  2. One-dimensional Quality, also known as performance attributes,
  3. Attractive Quality, also known as delighters,
  4. Indifferent Quality (neither improve or detract from satisfaction), and
  5. Reverse Quality (reduce satisfaction when achieved).

Most typical implementations of the Kano model tend to focus on the first three areas.   (more…)