Credit to @ChrisSims who I first saw running a session like this at an AONW conference. I have used this exercise to help teams understand how a they can reach consensus in estimating work regardless of the differences in experience and skill-set amongst them.
Part 1
Divide your room into equal teams (6 – 10 people on a team works well). Each team given a list of fruits and vegetables on large stickies: (Add a single number of 1 – 10 on each sticky to represent a priority order for the items – to be referenced later)
- Chayote Squash,
- Potato,
- Pineapple,
- Apple,
- Banana,
- Orange,
- Coconut,
- Blueberry,
- Durian,
- Grape.
Task 1:
Order the list from left to right, smallest to largest, in how much complexity and risk is involved in peeling and eating these items. (Time boxed 5 – 10 mins) As facilitator, you should also play the role of Product Owner (PO) and Subject Matter Expert if the teams need clarification. When complete ask for a spokesperson on each team to explain the reasons why they picked their order. All teams typically have some similarities. The results often reveal differences between the groups in knowledge and experience as well as some assumptions which could have been avoided by asking the PO some questions during their 5 minutes. For example, even if an item could be eaten without peeling – thereby smaller in complexity and risk – the requirement was it needed to be peeled first. Similarly, the potato and squash are required to be cooked before eating. I’ve seen teams explain they would smash a fruit or vegetable as a method for peeling, which is fine, but as a Product Owner you should expect higher quality.
Task 2:
Apply T-Shirt sizes using relative sizing. Place stickies indicating XS, S, M, L, XL above the list of fruits and vegetables.
Each team decides which single item represents a medium, their “Anchor”. This item is placed under the medium sticky and every other item is compared to this and asked the question, “Is this bigger, smaller, or the same size.” Those items are then placed in the appropriately sized bucket. We now have a backlog arranged by relative size which the entire team agrees on.
Task 3:
Overlay the modified Fibonacci sequence in stickies above the T-Shirt sizes. For example, XS = 1, S = 2 and 3, M = 5 and 8, L = 13 and 20, XL = 40, XXL = 60 and 100. The team can easily move similarly grouped T-Shirt sized items into a big or small mediums, big or small larges, etc. (5 or 8, 13 or 20, etc). Remove the T-Shirt stickies. We now have a relatively sized backlog using story points.
Note the story point size on each item. The Product Owner can now take the backlog and put it back into the original priority order. This view of the backlog may also reveal some previous unknowns, e.g. items that are too large and need further splitting may be sitting high in the priority. The team should plan to focus on grooming and splitting this work very soon.
Part 2
Now the team is ready to use this exercise on real stories from their actual backlog. First find a few stories which represent a medium level of complexity and risk to the team, the “Anchor Story.” Then they follow the same methods used above to relatively size the rest of their work.
After a few sprints, and once the team has established its velocity, it is possible to reasonably and accurately forecast when an item might be taken and completed from a sized and prioritized backlog.
Related information: Why use story points over hours?
Games Simon Plays 