Menu: Facilitation

Prioritization pattern

Read voting results with the group and discuss the surprises.

Purpose

Turn a count of votes into understanding. Voting shows where the group's concern is concentrated. Only the discussion shows why, and whether the concern is aimed at the right nodes.

When to use it

Timing

Voting takes a few minutes. Give the rest of Prioritize to this discussion: about 5 minutes in a small group, and 10 to 15 minutes in a large one.

Steps

  1. Read the results on the board, out loud, from the most votes down.

  2. Ask about the top.

    This node got the most votes. Does that surprise anyone?

  3. Ask about the bottom.

    This one got very few. Does anyone want to make the case for it?

  4. Follow the arrows under the top-voted nodes. Votes land on the problems people feel. The problems underneath them are less visible, and often have few votes.

    What is underneath this one? How many votes did those get?

  5. Mark what the discussion changed. A node the group now sees differently gets a mark next to its votes, and it may join the nodes that go to Decompose.

  6. Confirm the reading, and go back to Prioritize to choose what comes next.

    Does this ranking make sense now?

Tips

Traps

Variations

Example

The 12 participants of the renewals session placed 36 votes on 14 problems. The top 3 surprised nobody: outages with 8 votes, sales promises with 7, and escalations with 6.

The facilitator asked for the case for a node with few votes. A support lead spoke for "Tier 1 support cannot see a customer's setup," which had 1 vote. Tier 1 escalates because it cannot see what the customer has, the support lead said, and nobody outside support knows that.

The facilitator then followed the arrows under "Reliability work never makes it into a sprint," which had 5 votes, most of them from engineering.

Step 1 of 2. The votes, as the group placed them.

The prioritization pattern on the renewals board, step 1 of 2: The votes, as the group placed them. 9 nodes and 8 arrows: 9 root / problem. A text version follows the diagram. [P]Sales promisescustom featuresto close deals [P]On-call ignoresalerts becausemost are noise [P]The roadmap isreshuffled forevery big deal [P]Large customersrun custom codepaths [P]Tier 1 supportcannot see acustomer's setup [P]Outages hitduring themorning dispatchrush [P]Most tickets areescalated toengineering [P]Customers hearabout outagesfrom theirtechnicians [P]Reliability worknever makes itinto a sprint Legend [P] Root / Problem Vote Flow: roots (bottom) → outcomes (top). Votes: each of the 12 participants placed 3 votes on the problems they consider most important.

Step 2 of 2. Following the arrows under 'Reliability work never makes it into a sprint' leads to a problem with 1 vote: tier 1 support cannot see a customer's setup.

The prioritization pattern on the renewals board, step 2 of 2: Following the arrows under 'Reliability work never makes it into a sprint' leads to a problem with 1 vote: tier 1 support cannot see a customer's setup. 6 nodes and 6 arrows: 6 root / problem. A text version follows the diagram. [P]Sales promisescustom featuresto close deals [P]The roadmap isreshuffled forevery big deal [P]Large customersrun custom codepaths [P]Tier 1 supportcannot see acustomer's setup [P]Most tickets areescalated toengineering [P]Reliability worknever makes itinto a sprint Legend [P] Root / Problem Vote Flow: roots (bottom) → outcomes (top). Votes: each of the 12 participants placed 3 votes on the problems they consider most important.
Diagram as text: The prioritization pattern on the renewals board

Steps:

  1. Step 1: The votes, as the group placed them.
  2. Step 2: Following the arrows under 'Reliability work never makes it into a sprint' leads to a problem with 1 vote: tier 1 support cannot see a customer's setup. Changes: removed "On-call ignores alerts because most are noise", "Outages hit during the morning dispatch rush", "Customers hear about outages from their technicians". arrows removed: "On-call ignores alerts because most are noise" influences "Outages hit during the morning dispatch rush"; "Outages hit during the morning dispatch rush" influences "Customers hear about outages from their technicians".

After the last step:

Nodes:

  • Root / Problem: "Sales promises custom features to close deals" (7 votes)
  • Root / Problem: "The roadmap is reshuffled for every big deal"
  • Root / Problem: "Large customers run custom code paths" (1 vote)
  • Root / Problem: "Tier 1 support cannot see a customer's setup" (1 vote)
  • Root / Problem: "Most tickets are escalated to engineering" (6 votes)
  • Root / Problem: "Reliability work never makes it into a sprint" (5 votes)

Arrows:

  • "Sales promises custom features to close deals" influences "The roadmap is reshuffled for every big deal"
  • "Sales promises custom features to close deals" influences "Large customers run custom code paths"
  • "Large customers run custom code paths" influences "Most tickets are escalated to engineering"
  • "Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"
  • "The roadmap is reshuffled for every big deal" influences "Reliability work never makes it into a sprint"
  • "Most tickets are escalated to engineering" influences "Reliability work never makes it into a sprint"

Two paths lead into that node. One comes from sales promises, through the reshuffled roadmap. The other comes from escalations, and under escalations sits the node with 1 vote. The time engineering wanted back was going, in part, to tickets that tier 1 could close if it could see a customer's setup.

The vote did not change. The 3 top-voted problems still went to Decompose. The facilitator marked the 1-vote node, and the support subgroup took it into its deep dive. It was the first problem resolved after the session.