Banish “Priority” and “Prioritization”

Nov 11, 2021 3 min read
Banish “Priority” and “Prioritization”

Eliminating proxy variables empowers team members to make dynamic, good-quality risk decisions.

You might have noticed that we have purged the use of the words “priority” and “prioritization.”

“Priority” is something that Don Reinertsen would refer to as a  “proxy variable.” It is an artifact that masks real risk information,  such as “cost of delay,” required skills, technical impact, transaction cost information, and so on.

Our goal with a Kanban system’s visualization is to find ways to  capture and visualize the true risk information that the business is  managing. Classes of service do this very well, so long as the policies  that define what it means for an item to be of that class—and how an  item of that class should be handled—are made very explicit.

“Priority” then becomes something that can be decided dynamically  when a pull decision is made. Eliminating proxy variables empowers team  members to make dynamic, good-quality risk decisions. It reduces the  need for coordination meetings, and it improves transparency. It also  obviates the role of middlemen who determine “priority.” This largely  explains why a role such as Product Owner is generally not required  with Kanban. *

“Prioritization” is also no longer required with Kanban. The act of  prioritizing a backlog into some form of stack ranked list implies some  amount of crystal ball gazing to second guess the future. Such activity  is considered “waste” in Kanban. Backlogs should remain an unordered  list. Pull decisions should be made dynamically when a virtual kanban is  available and is signaling capacity.

Replenishing a Slot in an Input Queue

When we select something to replenish a slot in an input queue, I  prefer the terms “selection,” “scheduling,” and “replenishment,” rather  than “prioritization,” as we aren’t prioritizing a set of things in a  backlog, we are selecting something from a (usually) unprioritized  backlog to place in our input queue. Scheduling implies that we chose to  select an item for queue replenishment based on some plan or delivery  schedule, or based on another dimension of risk being managed, such as  the market risk of change. We might choose to schedule table stakes  features early. This means that they will be given priority when we  are replenishing the input queue early in the project. Scheduling  is definitely an optional practice, whereas selection and replenishment  are necessary to facilitate the flow in the kanban system.

When we select something to pull from an earlier stage in a  workflow, again, I prefer the terms “selection” and “pull,” based on the  policies in the classes of service package and the pull criteria (also  known as “definition of done,” or “exit criteria”). So “priority” and  “prioritization” go away. They are replaced with “risk profile” and  “class of service” (to replace “priority”), and “selection,”  “scheduling,” and “replenishment” (to replace “prioritization”).

Effect of Priority and Prioritization Vocabulary on Roles

Using “priority” and “prioritization” is wasteful. They encourage  roles/positions for people who do mostly non-value-added coordination  work, and they add to the transaction costs of flowing work through the  system. Prioritization is an activity performed at a point in time that  presupposes predicting the future. Kanban encourages deferred  decision-making and dynamic prioritization based on policies written to  accommodate the risks being managed.

I am finding that by encouraging teams to abandon the use of words  such as “priority” and “prioritization,” which are associated with an  older paradigm, a mindset shift to a flow-based approach is easier to  achieve. This mindset shift improves the quality of  the kanban system design and risk management. Better risk management  should lead to better satisfaction for all stakeholders.

* Where the role of Product Owner is observed in a Kanban  implementation, it is generally an artifact of the process in use before  Kanban was adopted. Under the core principles, “You start with what you  do now,” and “Initially, respect current roles, responsibilities, and  job titles,” if what you do now involves a product owner, that role is  likely to continue for some time, until it is generally accepted that  the role has been obviated, and a new role is found for the individual  currently playing the product owner.

Sunday, March 20, 2011

Great! Next, complete checkout for full access to Kanban Maturity Model Blog.
Welcome back! You've successfully signed in.
You've successfully subscribed to Kanban Maturity Model Blog.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.