Many agile teams use planning poker to estimate the relative size of items in their product backlog. Yet the usual planning poker with the (rounded) Fibonacci numbers can be applied the wrong way. Or better, in a suboptimal way. Fruit Estimation Poker to the rescue!
What is Fruit Estimation Poker?Nice friendly cheap alternative to Fibonacci poker – Alistair Cockburn
Compare it to planning poker, but with fruit instead of Fibonacci numbers. Also, instead of 13 cards (0,1,2,3,5,8,13,20,40,100,?,coffee cup) we have only nine:
- Cherry: really small.
- Strawberry: small. Used as the yardstick.
- Kiwi: medium
- Orange: bit bigger than medium.
- Grapefruit: rather large.
- Melon: very large. Please slice it.
- Fruit blender: could contain anything. Please clarify the item before you make me estimate it.
- Toilet paper: enough fruit! Please give me a break.
How to play Fruit Estimation Poker?
- if everybody agrees on a fruit symbol, write the name of the fruit next to the item. If the fruit chosen is a melon, have the person responsible for the item (product owner) slice it. Add the slices to the list and estimate them separately.
- if people disagree, have the person with the smallest fruit type chosen explain why the item is only that small. Have the person with the biggest fruit type chosen explain why the item warrants such high estimate. Reestimate afterwards.
- if two or more people chose the toilet paper, have a break.
- if estimates vary and one or more people have chosen the blender, have the person responsible for the item explain it and reestimate. If the explanation does not help, set up a spike for this item and reestimate later, with the results of the spike in mind.
Properties of Fruit Estimation Poker versus classic Planning Poker
- You can’t calculate with fruit sizes: this can be a disadvantage but also an advantage: “we can do either four items of size 5 either one of size 20″ looks reasonable, but in practice, 20 could mean anything from 15 to 30. With fruit estimations, you won’t say “either we do five strawberries, either one orange”. The scale is ordinal, not metric.
- You won’t make compromises: with planning poker, if five participants say “8″ and four say “13″, you are tempted to average them out and write “10″ as size. With fruit estimations, no-one will say “five oranges and three melons” means “grapefruit”.
- It’s intuitive: you don’t have to explain why the “values” are such an odd series, or that you can’t show two cards (“3+8=11″). Also, less choice means faster decisions.
- It’s more fun! (you are even tempted to bring a fruit basket with actual fruit for everybody…)
But then how can you determine how many items to tackle in a sprint?
- For the first sprint, like with planning poker, use gut feeling. Start with the low hanging fruit (if any) and keep adding items to the selected product backlog until you feel you can just eat it all in one sprint.
- Keep a list of “reference fruit” and consumed hours: for every fruit type except melon, have a low, normal and high number of hours that were actually consumed by this fruit type. For example, for your team, strawberry can mean 4h – 8h – 14h. Continually update this list and use the actual figures and the capacity estimate for a sprint to determine how much fruit to put in the basket. You can then even make strong commitments for some items (“yeah, we’re pretty sure we can do these three oranges and the kiwi, and we think we’ll be able to fit in the grapefruit as well, while we know that it is very unlikely that we will finish this kiwi as well”).
- Of course you could also switch to an agile method that does not prescribe sprints, like Kanban…You could then track lead times per fruit size, for example.