Agile Coach Journal

Prioritization of desired product functionality is often ad-hoc. Balancing the needs of all stakeholders is a challenge. A client recently shared a technique for gaining consensus on priorities and gave me permission to share it.

Context

I was invited to facilitate a Road Mapping exercise for an internal IT product that supports a global sales staff. Sales are for equipment and supplies manufactured by the company. We had representatives from several locales and business units. The challenge was to reach a consensus on product enhancement and improvement priorities.

Identifying Features

We spent the first half of the workshop developing a backlog of new features plus known defects. Features were identified by each stakeholder group independently. Some were epic-sized, some story-sized. The IT Department was a first class stakeholder, representing payback of technical debt and infrastructure needs. Defects and technical debt items were collected into functional areas.

When each group had their features up on the wall they were shared using two methods.

• First, each group was invited to look at the stories from the other groups. I call this a “Science Fair”. It is a useful technique when facilitating multiple groups at once. It gives diverse groups a chance to cross-pollinate; ideas from one group can trigger similar or different ideas for other groups.
• Second, each group presented their features in general terms to the rest of the group. This started us toward convergence and consensus by showing what sorts of things were valued by each group.

Convergence

We then did a Product Box exercise (see Innovation Games) to draw out similarities and differences across the stakeholder groups. We did this in mixed teams to start breaking down the differences in stakeholder expectations.

Next the features were clustered by “likeness”, meaning “things that are similar”. This is different from categorization and the difference is important. Premature categorization can lead to a different set of groupings. Instead, we just looked for similarities in terms of who benefits and what kinds of user activities are enabled. This gave us a better balance across stakeholder concerns because every cluster had requests from more than one stakeholder. In contrast, pre-categorization could have led to more stakeholder-specific groupings and, in turn, more difficulty in achieving consensus.

Once we had the groupings, we put names on the clusters. Those names then represented the feature areas to be prioritized.

For this exercise, we drew on the methods described in “The Workshop Book”. It is a powerful book for facilitators. Three things from the book were particular helpful:

• “Consensus” does not mean agreement by everyone. It means “a common understanding that allows the group to move forward together.” This definition saves a lot of anguish and time.
• The divergent- convergent activity framework that we use often in the Agile world helped put a structure on the workshop. It is similar to the Data-Insight-Action structure many of us use for retrospectives and identical to the ORID framework (see The Art of Focused Conversation).
• Clustering of ideas followed by Naming of the clusters is a liberating way to aggregate information from diverse sources.

Prioritizing Features

Once we had a common vision and the features identified, the next step was to decide what development order made the best sense. The goal was a Road Map level development strategy rather than a detailed release plan. At this point we were not sure of how many teams would be needed or how much each feature would cost.

We discussed some methods of consensus prioritization including dot voting and a variation on Planning Poker. The wrinkle was that we did not have equal representation from all stakeholder groups. So we decided to do it verbally, en mass, with all 15 people present. Knowing the challenges of reaching consensus with that many people, I approached this cautiously. One participant pre-empted my facilitation with a proposal and, recognizing this as a good opportunity to increase client ownership, I stepped to the back of the room while he presented his technique. What resulted was the gift I want to share.

The first step was to identify useful criteria for determining priorities. We got this set:

The participant who gave us the method advised that more than 4 criteria would be problematic, so we then distilled the list to the 4 most important. In the process, one split into two and a new one appeared, a nice evolution in thought by the group.

We then created a matrix with the criteria as rows and a simple scale of Low, Medium, High as columns. We next assigned a priority number to each cell in the matrix as show here. We started by asking which cell was the absolute highest priority and assigned it the 0. You can see that features with important compliance requirements trump everything else. The company sells products in a highly regulated domain, so this was not such a big surprise.

The group agreed that a high likelihood of increased sales was the next highest priority. We then worked down in priority (up in number). You can see that a high likelihood of decreased cost ranked second. Next was medium likelihood of increased sales. Priorities 1-3 align with our traditional Agile principle of seeking maximum business value.

From there, the picture got more interesting. Ease of implementation ranked high. Minimal compliance impact ranked lowest. Low increased sales is still medium important. Medium compliance impact is rated low.

At one point around 6 the group got stuck, having trouble assigning numbers in the middle range. So I used a facilitators’ trick and drew them to the other end of the spectrum. I invited them to place 11, 10, 9, etc. With both ends filled in, the middle ground became easier to see and the remaining matrix filled in quickly.

Applying the Matrix

Finally we collectively processed the features identified earlier and assigned a number from the matrix to each one. If a feature would help the sales people sell a lot more product, it got a value of 1. If a feature was absolutely required to meet regulatory standards, it was a 0. If it was super easy to implement, it got a 4. And so forth. This was a ranking, not an exclusive assignment. We had more than 12 features to prioritize. Features with the same priorities will be dealt with later when we have more information about teams, team capacity, budget, etc. Their general position in line was established.

Using the resulting priorities we were able to lay out a Road Map for the next 12 months. This was our primary goal. We also achieved many secondary goals including consensus building, learning the value of removing duplication in user functionality across geographies, appreciation for the role of IT in supporting the business and general networking for a globally distributed population having common needs.

Conclusion

Simple, lightweight tools can be very helpful in reaching consensus and collective ownership. Simplicity can help a diverse group stay focused on the work to be accomplished and avoid getting lost in the details. This matrix prioritization technique is simple to use and promotes confidence in the outcome.