Order Voting

When you need to quickly vote between a set number of options, simply asking people to vote one or the other sometimes isn’t enough as you only get the top result. There might be a compromise that suits everyone, and that’s what Order Voting is designed to help with.

Pros / Cons

  • Works with up to 10 people, more than 10 is difficult
  • Very visible, suitable as a conversation starter
  • Can be easily measured
  • Shows potential compromises
  • Needs a lot of space (and a surface)

Materials

You’ll need an obvious indicator for each topic. We suggest 4 or less topics otherwise it gets confusing quite quickly. Agility cards work great for this.

The Method

1. State topics or ideas and write them somewhere clear

Example:

 
 

2. Individuals order the symbols to reflect their thinking and place them in a grid. Can do it face down if you would like to do it blind. Just turn them over once everyone has submitted. Now’s a great time to take a photo if required.

Example:

 
 

3. Should you choose to, you can measure your results

Example:

 
 

9:00 / Blue: 4 + 4 + 3 + 4 = 15

9:30 / Amber: 2 + 2 + 4 + 3 = 11

9:15 / Red: 3 + 3 +  1 + 1 = 8

9:45 / Green: 1 + 1 + 2 + 2 = 6

4. If the outcome isn’t clear, a discussion is had about the results.

Example:

Jim: It seems that 9:00 is the consensus

Steve: Yes, even though I chose 9:30 I can see that you and Jessica weren’t keen

Jessica: Yes I often have meetings at 9:30 so I’d rather do them earlier

Darryl: Great let’s do that then

5. Vote is recast as necessary

 

We'd love to hear how you've used this technique in your teams. Why not leave us a comment below?

Confidence Voting

Confidence voting is a simple way for everyone to vote on a topic or theme. It’s easy to implement, fast to gauge feedback and can be used any time.

Pros / Cons

  • Gain a visible, fast understanding of buy-in from a group
  • Can be easily measured and tracked against decisions made
  • Involves everyone in the group in a decision

Materials

You’ll need 6 indicators showing the numbers 1-5 and a blocked symbol for each participant such as Agility Cards.

The Method

1. State the topic or idea

Example: Have bacon sandwiches every Friday morning

2. Individuals choose a symbol which reflects their thinking:

3. Individuals hold up their indicator (but don’t reveal) when they’re ready to vote

4. Once everyone is ready the cards are revealed for everyone to see

Example:

Confidence 2.png

Average: 2.25 (Blocked)

5. Discussion 

  • If no-one has blocked the vote, and we are happy to proceed with the idea, we can score the buy-in from the team – I suggest taking a photo of the indicators and taking an average at a later date.
  • If the goal is consensus, reservations associated with low scores should be explored as a team and a revote might be cast. If reservations are strong, they should probably be explored outside of a team setting.

Example: 

Darryl: I blocked the vote. I don’t eat meat.

Steven: Oh me too, that’s why I wasn’t keen.

Jessica: OK what would you rather have instead of bacon?

Steve: That’s a tough one, I’d be keen on a cheese toastie.

Darryl: Yes that sounds great, shall we revote?

6. Vote is recast as necessary

Example:

Average: 3.75

We love this technique for achieving fast concensus, but what do you think? We'd love to hear feedback or how you've used this with your team!

10 Tips To Get The Most Out Of Team Voting

Team voting can be a great way to pave a way forward that everyone loves, however there are some common pitfalls to avoid. Here are our top ten tips for voting in an Agile environment:

  • Make voting visible - use cards or whiteboards to bring your votes to life
  • Measure the outcomes of your voting - if you measure the reasons why you made a decision it's much easier to reflect later
  • Give everyone the opportunity to take part - all levels of experience and disciplines are opinions worth listening to
  • Do ‘blind votes’ where possible to avoid people leading the vote - quiet individuals may look to others, expose any lack of understanding so we can build on it
  • Listen to why people voted the way they did - after explanation, misinterpretation or alternative paths forward might become clear
  • Be prepared to compromise - it's impossible for everyone to get their own way all the time
  • Be honest, truthful and non-aggressive - not speaking your mind will only end up causing more pain in the long run
  • Use voting methods that are quick to implement - no-one likes spending ages casting a simple vote
  • Use the right voting technique for the job - otherwise you'll end up with bad or awkward data
  • Don’t take the result of the vote blindly forward without conversation - initial results are rarely the correct decision

What top tips have you got? We'd love to hear them.

Token Prioritisation

My favourite technique for prioritising a backlog is to use tokens. I think the first time I encountered this method we used sticky dots but after much trial and error, I now use physical tokens as having something quantifiable and real in your hand seems to help to prioritise the work and people tend to be more engaged. This would work with any token (Agility Cards, Poker Chips, magnets, jelly beans, etc…). Using this technique you can prioritise large backlogs (up to about 100 items) in just a few minutes. The output is a consensus-generated prioritised list that can be then talked about and modified as necessary. This is a lot easier to do once an initial order is established.

Pros/Cons

  • Very interactive – engages people really well
  • Involves the whole team – everyone’s voice is heard
  • Runs the risk of not being a carefully thought about order

Start by giving some cards to each ‘player’. A player is anybody who is interested in the priority of the work, this should include the business and any technical staff involved.

My suggested values are as follows:

  • 1x Black Cards (10 points)
  • 2x Green Cards (5 points)
  • 2 Orange Cards (2 points)
  • 3 Red Cards (1 point)

This gives a good number for a large backlog, for smaller backlogs use a smaller number of cards.

Setup

If your tokens don't have values on them, write the values somewhere clear that everyone can see. Print and lay all the items to be prioritised down so that the players can see all the requirements.

How it works

Ask the players to vote for which items should be prioritised with their chips. They can put multiple chips on 1 item if they like. I like to use a time limit of 5 minutes, the timebox helps them focus.

Add up the values, write the total on the item and prioritise based on these values.

As with any prioritisation method, this initial order should be a cause for a conversation. I would expect the Product Owner to take this information and re-prioritise as necessary but the end-to-end time should be greatly reduced.

What other prioritisation techniques do you use? What tokens are best?

MoSCoW Prioritisation

The concept of proving an end-to-end process is fundamental when starting Agile projects. With the teams I coach, I encourage them to get something (anything) in use/live as soon as possible. This engages the customer immediately, creates immediate learning and highlights unexpected bottlenecks in the end-to-end process.

This is very similar to a ‘Hello World’ software development concept that uses the smallest amount of code possible to write the phrase ‘Hello World’ on the screen. It is one of the simplest programs a developer can write and is often used to show that a language is installed correctly, the code compiles successfully and that the release environment is capable of delivering value to an end user.

BALANCING THE MVP

The ratio of the Minimum Viable Product (MVP) to other items on the backlog has a direct relationship with any time constraints you have. As you add more and more items to the MVP it puts more pressure on any deadlines you have, potentially forcing your hand to delay a release rather than negotiating scope that could wait until later. My advice here is to be harsh with your MVP, if you get it all done and have time for some other priority features then that's great, at least then you have the option.

MOSCOW

We can use the MoSCoW method to help prioritise and identify our Minimum Viable Product. It works by splitting the backlog into 4 categories:

 

MUST

The items in the ‘Must’ category are critical in order for the product to be usable. This is your MVP. To validate the items, take an item in your backlog and ask yourself this question:

If I had completed everything else on the backlog and this was the only remaining item left to do before getting this product in use, would I go live anyway?

If the answer is yes, the item is not part of the MVP, if the answer is no, then it probably is.

Items in your MVP should be prioritised to optimise for feedback and build speed, not necessarily customer value

SHOULD

The items in the ‘Should’ category are items which add a lot of value but you could initially go live without.

Items outside your MVP should be prioritised by customer value.

 

COULD

Your ‘Could’ items make up your nice-to-haves. These are the go-to place if the scope of a release needs adjusting.

 

WON’T

These are the items that after discussion don’t make it into the release or backlog. They are still useful to store and call out explicitly so that the stakeholders are clear what is not going to be done

 

HOW TO OBTAIN THE DATA

DELPHI METHOD:

Add MoSCoW tokens to planning poker or delphi estimation to easily identify a consensus view.

AFFINITY METHOD:

Place 1 copy of the token on the table with print outs of the items to be prioritised and ask the team to move the items as necessary into each category. Encourage conversation as necessary!

What problems could you forsee with MoSCoW? How does your organisation determine their MVP?

5 Deadly Assassins of Product Planning

When thinking about prioritisation for a new product. There are 5 assassins waiting to strike. They sit there, hidden in your backlog, undetected until the time is right and just when you think you're making progress, they make themselves known. In this blog we talk about the 5 assassins of product planning and strategies for how to combat them.

 

THE ASSASSINS

Data Migration

If you are expecting that data you’re planning to migrate from an old app is going to come without a fight, think again. The way you extract, transform and load the data can be extremely unpredictable.

Data Quality

It’s not just about moving data, but also about the data itself. If the data isn’t clean, in the right format and consistent you are likely to run into problems down the line.

Data Integration

Perhaps you’re not intending to move data at all but are planning to integrate with another product. Even if the API is fully documented, it doesn’t mean it will work exactly as written.

Path-To-Live

We need to understand and prove how our software is distributed, all the way through to live. There’s no value building software if it never sees a live environment.

Third Parties

Third parties have been known to make some pretty bold claims. Outsourcing seems like such a great idea – new relationships are particularly at risk of introducing dependencies that you can’t control which cause headaches down the line.

 

COPING STRATEGIES

If you suspect any of these assassins are lurking in your product, my recommendation is that you prioritise a small, demonstrable, part of your product as soon as possible that tests any assumptions we might have. Then you have the most time available to react if something is unexpected.

What you're looking for is a tracer bullet style piece of work - a production quality piece of valuable work that proves an end-to-end system. It's all about cutting that initial feedback loop down to as small as possible.

Let's look at some examples:

  • Data Migration - A script that loads one piece of data from the real source, transforms it into target format and saves it into your database.
  • Data Quality - A script that pulls in 10 random records from source data and displays it on the screen for review by a human.
  • Data Integration - Sending and receiving a request to an API for a single piece of typical data.
  • Path-to-live - Take the phrase 'Hello World' through to a production environment and display it on a web page. 
  • Third Parties - Third parties are a little different, I would look to prioritise a feature which has a large amount of required feedback from the customer and I would want to see demonstrable releases to a production environment every week. 

The above are only examples, I'm sure in your specific context you have particular needs that can't be addressed by generic content. So what's different for you? What assassins do you have?

Affinity Estimating

In Affinity Estimation, all participants estimate different items at the same time and exceptions are discussed in more detail. It’s great for large backlogs or initial/distant estimates.

Pros/Cons

  • It is very fast, allowing to estimate large backlogs very quickly
  • It highlights assumptions and misinterpretations by exception
  • Everyone is involved in the estimate
  • It is very easy for experts to ‘lead’ the estimating

Tools

  • Set of estimation units in card form (Fibonacci, T-Shirt Sizes)
  • Additional recommended cards:
    • Infinite (Too big to estimate)
    • Question (Unable to estimate with existing information)
    • Red, Amber and Green cards for confidence estimating
  • A number of items to estimate, printed or written on pieces of paper/card

Some coaches may suggest doing this in complete silence, but in my personal experience I have found the conversation that results from this exercise helps create some shared understanding of the work which is worth the extra time it takes.

Flow

To set up, create the following - probably on a large flat surface:

If you have no reference point, start by finding a typical mid-complexity piece of work that you’re pretty confident with and place that in the middle of the wall/table, place that in the 5 column in the high confidence row.

Next all team members at once consider other work items and add this to the wall one by one, thinking about the relative complexity of the other items and how confident you are with your estimate.

Keep in mind that for the work item to be a complexity ‘5’ this should be about the same as a ‘3’ and a ‘2’ put together.

Any person in the estimating process can move any work item at any time, even if they disagree, however, if you find a work item moves back and forth, this should be discussed. This avoids unnecessary conversation about items that everyone agrees are the same size.

If someone feels they are unable to estimate, they can move the item to the question column. Then someone else can move it out of the question column providing they explain their estimate.

The above diagram shows an example outcome from an affinity estimation session. It’s quite common to add a numerical modifier to the levels of confidence when using the estimates to predict. For example:

  • Red = 2x Modifier
  • Amber = 1.5x Modifier
  • Green = 1x Modifier

We would then calculate optimistic-pessimistic estimates as follows:

As a result this total estimate for the work that we are able to estimate is 52-92points. With the knowledge that there are 2 items that need breaking down and adding to the estimate and 1 item that needs more information.

Do you think Affinity Estimation would work for your organisation? What problems could you forsee?

Planning Poker / Delphi Estimating

Planning poker is a consensus estimate generated through multiple rounds of synchronised ‘reveals’. It’s great for thrashing out detail and shared understanding.

Pros/Cons:

  • Multiple people estimate a work item at the same time, avoiding 1 expert ‘leading’ the others
  • It highlights assumptions and misinterpretations
  • It encourages group discussion, which increases the accuracy of an estimate
  • It takes a long time to estimate a large backlog

Tools

  • 1 set of estimation units in card form (Fibonacci, T-Shirt Sizes) for each team member
  • Additional recommended cards (1 set for each team member):
    • Infinite (Too big to estimate)
    • Question (Unable to estimate with existing information)
    • Red, Amber and Green cards for confidence estimating
  • A number of items to estimate, printed or written on pieces of paper/card

Flow:

  • Someone reads the description of the work item to the team
  • The team consider the complexity of the work and their confidence level. They collect 1 estimate and 1 confidence level card (Red = Low, Amber = Medium, Green = High)
  • When someone feels they have a number they raise their 2 cards in the air to show they are ready to estimate
  • When everyone has their cards in the air, a rock-paper-scissors style 1-2-3 is called and everyone shows their estimate using their hands
  • If the estimate is inconsistent around the room, the highest and lowest estimates are compared and discussed*
  • The process is repeated until a consensus is made
  • The complexity estimate once agreed is written on the work item
  • Choose the next work item and follow the steps again

*If there is inconsistency, for example a ‘3’ and a ‘8’ estimate confidence this is a good cause for discussion, the team member estimating ‘8’ may have more detail on why a work item is more complex due to information that others may not be aware of or know that this would rely on another piece of work being done. Alternatively, the team member estimating ‘3’ may have knowledge of a similar work item that has been solved before and therefore makes this work item easier.

This is especially true when stakeholders estimate differently to team members as this can highlight a misunderstanding in requirements or complexity.

10 Tips to Get The Most Out of Your Estimation Sessions

Estimation can be a real pain in the backside. Here are our top ten tips for estimation in an Agile environment:

  • Understand the value that estimating is bringing your team and organisation
  • Don't use an electronic tool during your estimation sessions. It always takes longer. If you use an electronic tool to track your work, type up your results after.
  • Timebox each estimate. If it's taking too long, park it and discuss outside of the meeting with less people until it's sufficiently detailed to estimate.
  • Don't estimate anything you don't have to.
  • Always prioritise estimates for work you are doing sooner rather than later.
  • Be honest in your estimates. Have a reference item to compare you estimates to so you can validate.
  • Ask questions if you don't understand the work. If you're worried you're taking up too much time by asking questions find someone after and ask to pair.
  • I like the Product Owner's to estimate too. It helps show any discrepencies in understanding. The team's estimate is still the estimate.
  • Involve several people and disciplines in estimating your work.
  • Don't stress about estimates. By definition they are inaccurate.

What top tips have you got? We'd love to hear them.