management@fullframemarketing.com

Product Prioritization: Planning Poker

Stop gambling on what to do next… by playing poker

Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our fourth installment, we take a look at ‘Planning Poker’ also known as ‘Scrum Poker’.
At Left Travel, we enjoy using ‘Planning Poker’ when it’s important that the team needs to come to a consensus. This technique is perfect for:

• Aligning different stakeholders
• Extracting silo-ed information from stakeholders
• Keeping meetings interactive and fun

What is Planning Poker and how does it work?

At a high level, ‘Planning Poker’ is a prioritization technique where multiple stakeholders get together and establish the value of a project, feature, or idea. For the purpose of this blog post, we’ll discuss ideas.
The technique is gamified to estimate value. Stakeholders are presented with an idea and each one of them votes on how valuable they think the idea is by using a set range of cards or poker chips with varying values. Votes remain hidden until all members have voted to avoid influence from other members. Once everyone is decided, the votes are revealed at the same time.
After everyone has presented their votes, the stakeholders who voted with the highest and lowest values explain their reasoning. The voting process repeats until the team agrees on a value for the idea.

How to Play

Step 1: Deal Cards or Poker Chips

Each person is given a set of cards or poker chips. The value of the cards or poker chips should be set as 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. While ‘Planning Poker’ can be played with different values (like a Fibonacci sequence), what matters most is that the higher the bets get, the larger the gap is between the next lowest and next highest values.

Step 2: Rules & Establish Values

The moderator or scrum master explains the rules of the game to the group (explained in the following steps).
Next, the moderator establishes what the number value of each card or chip is worth. Since value is subjective, it is crucial to complete this step before starting the exercise. Take the time to go over a few past ideas that are complete and assign them a value. It is best to pick ideas that vary strongly in value to allow the stakeholders to be able to easily compare low, medium, and high-value past ideas to new ideas. Use the phrasing ‘X idea is a 40 because…’

Step 3: Present the Idea

Next, get the product manager or owner to present the ideas to the group and ensure that there is full clarity on every aspect of each of them. The moderator can also act as the product owner for some or all of the ideas that are being discussed. Allow time for Q&A from the stakeholders.
Tip: Standardize the way the ideas are being presented to avoid a stakeholder over- or under-emphasizing specific ideas based off of their personal opinions. Set timing and structure requirements.

Step 4: Voting

Once everyone has had a chance to ask questions about the idea, it is time to vote. Each stakeholder selects a card or chip and places it face down on each idea. The higher the value of the card or chip the more important it is to the stakeholder. Once everyone has cast their vote, all of the votes are revealed at the same time. It is important to keep the votes secret until everyone is ready in order to make sure that the stakeholders involved aren’t influenced by others in the company — no matter what their role is.

Step 5: Discussion

Start the discussion by having the stakeholders that cast the highest and lowest votes explain why they gave the idea that value. Through this discussion new data can be discovered as the high and low-value voting members will often have additional information about the idea that others didn’t have prior to voting. For example, a stakeholder might know how an idea may possibly have a massive impact on another feature, or how the idea would be a big waste of time because it doesn’t impact any key KPIs.
The moderator will typically only need to call on those who had the highest or lowest value, unless a stakeholder who voted in the middle is very passionate about an idea. At some point in the game, most stakeholders will end up on the high or low end so they’ll get the opportunity to participate. If there is someone who constantly votes in the middle, call on them at some point to make them feel included in the discussions.

Step 6: Assigning Value/Voting Again

Assuming that not everyone assigned the same value to an idea, after hosting a discussion, have the group vote again. Repeat the process until the group comes to a value consensus (they all vote the same). Once agreed upon, assign the decided value to the idea and move on to the next idea.
Tip: If the stakeholders aren’t coming to a consensus and a revote has been cast, it is helpful to ask the stakeholders that are not aligned if they are comfortable adjusting their vote up (or down) to meet with the group. This usually works.
If it doesn’t work, note down what the scores from the group were and the members who wouldn’t adjust their vote. This is done not to single them out, but to make a reminder to approach them later so that you can dive deeper into their reasoning.

Step 7: Finishing Up

Once all of the ideas have a documented assigned value, sync up with the team that estimates the size (level of effort) of ideas.
Once the size has been determined, create a ratio of the idea/ feature/ project, to the level of effort. Give bonus points if the team can take the information and get it down to story points, sprints, days, etc. Once completed, there will be a list of prioritized ideas.
Tip: A simple 4-quadrant list with value and level of effort will help identify ideas that stand out.

The Benefits of Physical vs. Software

Last week, the Left Travel team did a ‘Planning Poker’ session to value some of our upcoming data projects. When prepping for it, I looked into the benefits of using physical cards/chips compared to using a software program.
I ended up deciding to use physical cards. I found that many of the paid or free ‘Planning Poker’ software options were either too cumbersome or tied to a roadmapping system. For our team, the effort to go through the onboarding process was too much of a pain. In saying that, if you’ll be using the ‘Poker Planning’ technique often, it might be a good idea to use software.
You can purchase ‘Poker Planning’ cards on Amazon or Mountain Goat Software.
Other Uses of Poker Planning: Backlog Grooming & Remote Teams
Outside of assigning collective value, the ‘Planning Poker’ technique can be used to groom your backlog and development estimations (sizing). It is recommended to use the Fibonacci sequence instead if you’re doing one of those.
‘Planning Poker’ also works really well with remote team members. The moderator will have some extra prep to ensure that the stakeholders have the card or chips before you start (software may be a better option for remote teams), but the voting and discussions work well if everyone is on a video call.

by management@fullframemarketing.com

Product Prioritization: MoSCoW

Must, Should, Could, Won’t

Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our fifth installment, we take a look at ‘MoSCoW’, a quick way to identify things that will surface to the top and sink to the bottom. The MoSCoW prioritization technique isn’t as refreshing as a Moscow Mule but, it’s still a good one.
It’s similar to the Stacked Ranking technique, but sometimes it’s either too hard or takes too long to get a ranking of the features you want to prioritize. If you find that features are too similar, and your team is ‘arguing’ over a feature that should be in the #3 or #4 spot, MoSCoW should be a good fit.

Besides a yummy drink… what is MoSCoW?

MoSCoW is an acronym to help you remember four different categories when you’re running a prioritization session.

• M = Must Have. Critical features that must be included in the product. If it’s not included, the product release will be a failure.
• S= Should Have. Important features, but not critical for the product. These could be features released in phase 2 or added into phase 1 if your team has extra development time.
• C = Could Have. Commonly called ‘Nice to haves’ aka ‘NTH.’ These features aren’t necessary for the release. As new information comes from users, these features may move to a ‘Must’ or ‘Should’, or to a ‘Won’t’ in future planning sessions.
• W = Won’t Have. Kill these ones. These features will be things that aren’t aligned with the goal of the product, or maybe the risk/value is in the wrong quadrant.

Wait. What about the two Os?! They don’t stand for anything but are just there to create a name that’s more memorable.
This is a good method when you need a quick ranking to start to paint the picture of what should be in the next release, in the MVP, or even in the next sprint.
I’ve found that MoSCoW works better in smaller groups. In larger groups, the nuance of a feature being in the ‘Should’ or ‘Could’ group may take away from the intention of getting a quick prioritized list.

Moderator Tips

This method is also enhanced when combining it with real Moscow Mules.
When coaching a team about this method, it’s a great idea to bring in real Moscow Mule cup as a visual aid. Having this visual helps your team remember this technique.

• Moscow Mule Cups
• Moscow Mule Recipe ?

by management@fullframemarketing.com

Product Prioritization: Buy-a-Feature

Using cash to identify key ideas

Welcome to ‘Product Prioritization’ — our series of tools, tips, and best practices for the skilled Product Manager to determine priorities and get results. Each month, we will highlight one of the dozens of popular methodologies and explain how to use it.
For our third installment, we take a look at ‘Buy-a-Feature.’
At Left Travel, we enjoy using the ‘Buy-a-Feature’ technique when working with internal teams or external users who ‘want it all.’ It’s always challenging working with stakeholders who want all of the features, all at the same time — this prioritization technique helps enable them to describe the value they see in the features in a new way.

What is ‘Buy-a-Feature’?

‘Buy-a-feature’ is a product prioritization technique used when a product is under development to quantifiably estimate how valuable a feature or an idea is. To do so, a product team will work directly with customers and key stakeholders to solicit feedback and prioritize enhancements or features which the participants want or value most.

How to use ‘Buy-a-Feature.’

Our team loves this prioritization technique, and as such, we highly recommend it under the right circumstances, such as during an in-person focus group. To use it, we’ve developed a game that breaks it into 5 simple steps:
Step 1: Make a feature list.
As a team, make a list of the features that need to be prioritized.
Step 1.5: *Optional* Assign each feature a price.
Give each feature on the list a value or price. The value or price should be based on the relative size, LOE, and scope of the project to represent the effort required to build it.
At Left, we’ve run this technique with and without prices. While both options work well, we’ve found that by having prices it helps focus groups that are outside of software development understand the actual ‘cost’ of a project.
Step 2: Get customers and stakeholders together.
Get your company’s stakeholders and/ or customers into a room (or on a video call) to start the game. Explain the features on your list to the group to ensure everyone has full clarity on their benefits.
Step 3: Give out the cash.
Give everyone in the focus group the same amount of money to use during the game. If you’ve assigned prices to the features as in Step 1.5, give them between 50–60% of the total cost of all of the listed features. This is to make sure they are being selective in their buying decisions.
Step 4: Have them buy.
Ask your stakeholders to “buy” the features they like. They can spend all their money on one or two, or spread it out evenly — it’s their “money,” they can spend it how they want to!
Observe the buying process and have the stakeholders explain why they spent money on the features that they picked. This is the Product Manager’s opportunity to listen to your customers and/ or stakeholders and understand both their individual and group ‘buying’ decisions.
Step 5: Collect observations for action.
Arrange the list of features by order of how much was spent on each feature (top=most money; bottom=least money). Now you have a list of features ranked and a value assigned to them.
Once the game is completed, use the ranked list and collected observations to make informed decisions on future product development based off of your customers’ and stakeholders’ needs.

Tips when using Buy-a-Feature:

• This technique carries more weight when done with end-users as it shows the value they see in the features they would use in the product.
  This game can be run either individually with a stakeholder, or in a group of stakeholders.
• If there are a few features that are bought with a similar amount of money, group them together. For example, a $5 difference between two features may be insignificant or subjective to the particular stakeholder, depending on how much money you gave the group.
• Allow ideas to flow from your participants. If new features or ideas come up, use the structure of the game to ask what the estimated value of the feature would be and where it would fit within the ranked list.
• For a fun twist, use real money. There’s something about handling real money that changes people’s buying behaviour.

by management@fullframemarketing.com