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.


The simplest definition of the term prioritization is determining what is most important. Prioritization creates order out of chaos (however fleetingly) by spending the time necessary to reflect on what is most important.  In today’s IT environment individuals, teams, and even organizations fail to prioritize well and then try to do thousands of things at once.  The cult of “multitasking” promotes starting everything and then juggling and time slicing to continually appear busy. Busy is confused with effective. Work that is smaller and less consequential is often completed before work that is important.  Stephen Covey uses the analogy of rocks, pebbles, and sand in a jar to demonstrate the impact of focusing on the less important work (sand and pebbles) before addressing the big-ticket items (rocks).  If you fill a jar with sand there will be no room for the rocks (See the video at


Work Entry: An Introduction, focuses on what work entry is and why it is the single most important part of determining whether a team is dependable, predictable, and even remotely agile. 

We will also have a visit from Jon M Quigley and his Alpha and Omega of Product Development. Jon and I discuss, wrestle, and chew on how the idea of a product backlog can exist in a project environment. 

Re-Read Saturday News 

We have read or re-read Fixing Your Scrum: Practical Solutions to Common Scrum Problems by Todd Miller and Ryan Ripley cover-to-cover if you don’t count the index at the back of the book (and I certainly do not). As a wrap-up, I briefly consider three points that came to mind during the re-read. If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems 

Next week we will start our re-read of Monotasking by Staffan Noteberg by laying out an approach. I am contemplating combining the re-read with experience reports as I try to put the ideas in the book to use. More on that next week.

This Week’s Installment 

Week 16 – Final Thoughts 

Previous Installments

Week 1: Re-read Logistics and Front Matter 

Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad 

Week 3: Breaking Bad Scrum with a Value-Driven Approach 

Week 4: The Product Owner 

Week 5: The Product Backlog 

Week 6: The Development Team 

Week 7: Embracing The Scrum Master Role – 

Week 8: Management 

Week 9:  Thinking In Sprints 

Week 10: Sprint Planning 

Week 11: Sprint Backlog 

Week 12 – Reclaiming The Daily Scrum 

Week 13: Deconstructing the Done Product Increment – 

Week 14: The Sprint Review 

Week 15: The Retrospective 


Speaking of Monotasking by Staffan Noteberg, in the next podcast, we will feature the interview I did with Staffan covering the book that we are about to re-read.  We discussed how to apply the ideas in the book to improve focus, productivity, and quality of life.

Controlling Entry

The majority of work entry problems are caused by eight problems. The eight problems often occur in clusters and are a reflection of organizational culture.  The eight are:


Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. This week we talk about five common patterns. On Tuesday I will include the PDF in the feed to see if I can spur a discussion about other patterns.  


Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. A simple work entry process for a Scrum team includes the following steps:

  • People write stories, ideas, or requirements of varying quality,
  • Those items are evaluated and cleaned up,
  • Updated, well-formed stories are added to the backlog (become product backlog items – PBI),
  • Once on the backlog, PBIs are prioritized (and re-prioritized), and
  • In time, PBIs are pulled into a sprint.

Over the past few months, I have been in traffic jams on the highway several times when traveling to our weekly hike.  In more than one instance someone has decided to pull over and drive on the berm.  In more than a few cases the outcome of this technique for getting things done ends poorly. Despite the unpredictable outcome, jumping the queue is practiced by many in traffic and even more when funneling work to teams. The consequences in information technology are far more predictable than driving, and they are ALWAYS bad.

Work Entry Is The Pipes

Work entry is not the sexiest topic in agile, as a matter of fact, the topic is generally not understood unless a team has mature (or maturing) processes for working.  In several recent conversations, I asked how individuals and teams get the work they work on.  The answers ranged from we triage the work with our product owner to the phone rings and somebody’s manager tells me what to do.  I was also accused of being a killjoy for bringing the topic up during a happy hour (note to self — don’t do that again). The comments are bookends describing the best and worst forms of work entry.  There are many shades of team-level work entry that are accommodations to behaviors the organization chooses not address. Three of the ‘in-between” approaches are:

  1. Prioritized Pull with Prioritized Incident Push
  2. Front Door Pull, Back Door Push
  3. Prioritized and Unprioritized Push with Incident Flow