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
- During Prioritize, as soon as the votes are placed and before anything is chosen for Decompose.
- After any later vote on the same tree, such as the vote that follows a review. See evolving the tree.
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
-
Read the results on the board, out loud, from the most votes down.
-
Ask about the top.
This node got the most votes. Does that surprise anyone?
-
Ask about the bottom.
This one got very few. Does anyone want to make the case for it?
-
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?
-
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.
-
Confirm the reading, and go back to Prioritize to choose what comes next.
Does this ranking make sense now?
Tips
- Ask what people had in mind. "What were you thinking of when you voted for this?" brings out the story behind a vote. Asking someone to justify a vote brings out a defense.
- Give the lone advocate room. A node 1 person argues for strongly may be the hidden issue the group has been avoiding. Let them finish before anyone answers.
- Speak last if you voted. A facilitator from inside the group reads the results, asks the questions, and gives their own view after everyone else. See the facilitator's role.
Traps
- Reading few votes as unimportant. Few votes means few people see the node. Deep causes are often the least visible nodes on the board.
- Explaining the result yourself. The moment you say why a node won, the group stops telling you why they voted for it. Ask, and wait.
- Reopening the vote. The discussion adds meaning to the votes. It does not replace them. If someone starts campaigning for a recount, mark their node and move on.
Variations
- A vote on outcomes. For an outcome with many votes, open its blocked outcomes view and read the problems in its way with the group.
- Verbal agreement. A small group may skip the dots. Ask each participant for the 1 node they would act on first, and why. Then ask the same 2 questions about the answers.
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.
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.
Diagram as text: The prioritization pattern on the renewals board
Steps:
- Step 1: The votes, as the group placed them.
- 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.