8 Techniques for Better Prioritization Meetings

When a CEO or client dumps an unexpected feature list on a product team, this can create confusion and division for all involved with the product roadmap. It seems all to often that prioritization meetings are disrupted like this, but I’ve got a better way. Team members should not be confused on priorities, because interpreting feature priority can add to stress by creating division between coworkers with different viewpoints. We can do better.

Engage the product owner, whether it be your boss or a client. Carve some time out of your schedules and set a goal to prioritize the next feature(s). We can add a little science to this process instead of leaving prioritization meetings open with the question, “So ok…what do we build next?”

By the way, we’re hiring at Revelry.

If you love open source software, have a look in our library and come to play.
Here’s our library.
Check out our Careers page for details.

Here are eight techniques to make prioritization meetings more efficient for your team. Each example includes a quick overview and suggestion for when to use it.

 

Buy a Feature

  • Overview: Give each story a cash value based upon their story point value. Each prioritizing stakeholder is then given a cash amount to “spend” on features equal to the team’s velocity. The features that received the most individuals giving cash become the priority.
  • Example: The “Buy a Feature” methodology is as simple as it gets. Try it out if you are working on a new team or teaching prioritization techniques to your team. Idea: Use cash from a Monopoly game set.

 

Opportunity Scoring

  • Overview: Opportunity scoring ranks epics based on their importance versus current satisfaction with the features that have been built within that epic. Epics that have not had any development done will receive a 0 for current satisfaction. Set an amount that delineates something as a “high” opportunity to be worked on. Features will then be taken out of that epic and be worked on during the next sprint. 
  • Example: When you are split between which epic to work on in general, perform this experiment to see what has the highest opportunity for ROI. Outline all of your epics and have the team rate each item with a score of 1-10 on the epic’s importance versus current customer satisfaction. An item with high importance and low customer satisfaction will be your opportunity.

 

Affinity Grouping

  • Overview: If you feel like you have completed all features and have hit a dead end, try this technique.  Affinity grouping is close to an all-out brainstorm on what to build next. This can bring out creativity from places you least expect it.  
  • Example: Have the team write features on sticky notes and put them on a whiteboard. Group similar areas of functionality together and define what is similar between the features. Examples may include “enhance overall user experience”, “decrease load times”, “increase number of successful checkouts”. Once grouped, have the team vote on what to work on next–the group with the most votes is prioritized.

 

Value vs. Complexity

  • Overview: A quick and dirty way to prioritize features. Create a graph with one axis representing business value and the other axis representing complexity. Have teams plot feature requests on the graph and review the results.  You’ll then have insight into people’s different perceptions of complexity.
  • Example: Are you currently experiencing arguments about how easy something is or what the payoff will be for the end user? Have the team plot feature requests on a value vs. complexity map to gain insight. Features that have a low implementation cost but have high value to the user are low hanging fruit and quick wins. Move from away from the origin and continue to choose features until you have enough story points to hit your team’s expected velocity.

 

Kano Model

  • Overview: The Kano model of prioritization is similar to the value vs. complexity scoring mechanism. Instead of comparing value versus complexity, the model compares the features function to the overall system compared to the delight that the feature will bring to the customer. For instance, user login and authentication are necessary for the overall product function but do not greatly enhance customer delight.
  • Example: If you are just starting off a project and you have a lot of system setup (product function) to knock out but the main stakeholder has provided a long list of pretty features, use the Kano model to demonstrate that the system must first knock out specific functions before building specific feature requests and a beautiful UX. Who knew that user management could be so boring yet necessary?

Kano Model

Image Courtesy: Product Plan

Story mapping

  • Overview: Story mapping is one of the most common and popular ways to prioritize. It’s a great way to prioritize items if you have a baseline feature set for a MVP. The prioritizing stakeholder will write user stories on sticky notes and prioritize them from top to bottom on what is most important. If you know your team’s velocity, have the team estimate each issue with story points to put a sprint schedule against the stories.
  • Example: If you’re just getting started on building a well defined MVP or relatively small feature within an enterprise system, start with story mapping. It’ll help the main stakeholder to clearly think through exactly what the user needs are, via user stories. You can plot a timeframe against your team’s velocity.  

 

Weighted Scoring

  • Overview: Weighted scoring allows stakeholders to achieve a clear cut read on what’s prioritized. This method ranks new feature requests across a series of different costs and benefits to create a weighted score for each feature. The features with the highest scores are prioritized.
  • Example: If your prioritization meetings are spread across multiple stakeholders and you’re facing a gridlock, try weighted scoring. This puts some hard science behind your decision making. Decide what your major initiatives are for the product, and the major costs, then score each feature request to see which receives priority.   

Weighted Scoring

Image Courtesy: Product Plan

 

Buckets of Features

  • Overview: The buckets of features can be helpful in tying product vision directly to what features get worked on during a sprint. A specific weight or percentage of velocity will get devoted to a “bucket of features.” For instance, if you are early on in product development you may be focused on new feature development. If you are post-launch, you may be focused on the bucket of features of UX improvements.  
  • Example: If you have multiple offices competing for development time (design pushing for UX changes, sales pushing for a streamlined ecommerce user flow, etc.) define what amount of velocity each bucket of features will receive. Then, give the relative story points to each office and allow them to choose which prioritized features will be worked on next.

 

Try out these prioritization techniques and see where they get you and your team.  Make sure whomever is driving the product vision (especially if its you!) engages with the team.  Have any other methods that have worked for you in the past?  Let us know in the comments!

 

Read more about design sprints and prioritization meetings at Revelry

Check out Lean Customer Development for New Ideas or let us know How we can help!

More Posts by Sean Rowland: