White Elephant Sizing - Agile Estimation Method

Agile teams need to estimate the size of their stories or product backlog items. The goal of the White Elephant Game is to get a quick estimate of the relative size of an agile project and the size of the individual stories before the project starts. It gives opportunity to everyone for their voices to be heard, and everyone contributes equally. Estimation is a key component of project realization. It projects the cost for Stakeholders, duration of the project for Product Owners, size or complexity for the developer. The white elephant game attempts to do this in a way that can be reliably fit into a given amount of time and keeps the focus on getting the overall estimation done rather than disagreements on the sizing of particular stories.There are significant difference between White Elephant Sizing Game and Planing Poker, so evaluate which one is better for your team.

White Elephant Preparation

A board (whiteboard or White paper chart or something like that) – divided into 5 columns(XS, S, M, L, XL) or divide it into 3 (S,M.L) columns or start with three columns and as per the need for more granularity add additional columns or divided by Fibonacci Sequence for estimation 1, 2, 3, 5, 8…
Timer or stopwatch
A set of prepared user stories – Print out/Write down all Product Backlog Items or user stories on separate cards. It can be just the summary or summary with brief description of user stories which is enough for the team to understand.
A set of cards
Tape or sticky note

White Elephant Rules

Team stand-up in a semi circle facing their sizing or white board.

Shuffle a deck of user story cards and put those with face down on a table just in-front of the board.

Start the timer which is the signal for the first member to perform the following steps:

Take a card from the top of the deck read it out and place it in one of the columns (a.k.a propose the estimation for that item).

Take one of the cards already placed on the board and move to another column (a.k.a change the estimate). If someone is moving a card, he/she needs to provide some reasons for doing it.

Pass, if all the stories are placed and they are satisfied with the story placement

The first person has only option to take the card from table and place it in the board as there are no other cards in the board. Once the action is done team member goes to the end of the queue and it is the next person turn. Repeat the above process for the other team members until there are no more cards to pick from, he/she can either take a new story or re-estimate that story.

Once all the stories are placed on the board, the team inspects the board and each member can propose to move one of the stories’ place. They can, later on, discuss it with the product owner and ask questions that will help them estimate those stories together.

While White Elephant is a fun exercise, it’s not just about the laughs. The resulting size buckets provide valuable insights:

Identify outliers: Cards placed in extreme categories (XS or XL) might need further refinement or breakdown.
Spot trends: Recurring patterns in sizing can reveal areas of complexity or missing information in the backlog.
Set realistic expectations: The overall size distribution gives a clearer picture of the workload for upcoming sprints.

Example – Online Fitness App

Let’s imagine our Scrum team is tackling a product backlog for a new online fitness app. We’ve got a mix of user stories, and White Elephant Sizing seems like a good way to get a handle on their relative effort.

Preparation:

Sizing Board: We set up a whiteboard with five size categories: Miniature (1 point), Pocket Rocket (2-3 points), Cardio Crusher (5-8 points), Ironclad (13-20 points), and Mountain Climber (21+ points).
User Stories: We write each user story on a separate index card, keeping them brief and clear.

The Game:

Shuffle and Deal: We shuffle the story cards and deal three face-down to each team member.
Take your turn: One player reveals their first card, reads it aloud, and explains why they think it fits a specific size category. We’ll call him Mark.
Discussion and Debate: Others can agree or disagree with Mark’s placement, offering their own perspectives and reasoning. For example, Sarah might suggest “Pocket Rocket” as the card involves less complex interactions.
Final Sizing: After a brief discussion, Mark decides to stick with his initial “Cardio Crusher” placement. He places the card on the board.
Repeat: The next player takes their turn, revealing and discussing their card. This continues until all cards are placed.

Example Breakdown:

Story 1: Implement user login and registration functionality (placed in Ironclad by most due to multiple integrations and security considerations).
Story 2: Design and build a personalized workout recommendation engine (placed in Mountain Climber due to complex algorithms and data analysis).
Story 3: Add the ability to track completed workouts and progress (placed in Cardio Crusher involving database storage and user interface updates).
Story 4: Allow users to share their workout results on social media (placed in Pocket Rocket as it’s a relatively straightforward feature).

Outcomes:

Overall Backlog Size: The distribution of cards across categories gives us a rough idea of the project’s overall complexity. We see a good mix of smaller and larger stories, indicating achievable workload for upcoming sprints.
Identify Outliers: Stories placed in Mountain Climber and Ironclad might need further breakdown into smaller units for better sprint planning.
Shared Understanding: Through discussion, everyone gained a clearer understanding of each story’s scope and potential challenges.

Remember:

Collaboration is key: Encourage open discussion and challenge sizing decisions constructively.
Relative, not absolute: Focus on comparing stories to each other instead of aiming for perfect point estimates.
Adapt and refine: White Elephant is a framework, feel free to modify the categories or format to suit your team’s needs.

Additional Techniques

To avoid any clashes or team disappointment for the final results you can employ few techniques like

Timebox: A rough formula is 2 x turn-duration x number of stories can be used to derive time-box. Some stories will take almost no time to estimate. Other stories or high-priority epics require more questions or interaction. Overall, they should balance each other out.

Never-ending story: It may happen that there are no agreement between the team members for a particular story. e.g. one card is moved from one column to another column and back to the first column and so on. To avoid this set a rule that

One card can be moved only N number of times or
After N number of times it becomes a Safe Card and can only be moved to higher estimate.

Final verification: As per the above rule the last user story card will be estimated by the last person but to avoid this the game should continue for one more round. The rule can be modified like

Last card can be either moved to another column or pass the turn.

You can use Hanoi Tower algorithm to make it more productive and fun.

Hanoi Tower algorithm is a mathematical game or puzzle. It consists of three rods and a number of disks of different sizes, which can slide onto any rod. The puzzle starts with the disks in a neat stack in ascending order of size on one rod, the smallest at the top, thus making a conical shape.

The objective of the puzzle is to move the entire stack to another rod, obeying the following simple rules:

Only one disk can be moved at a time.
Each move consists of taking the upper disk from one of the stacks and placing it on top of another stack or on an empty rod.
No larger disk may be placed on top of a smaller disk.

The minimal number of moves required to solve a Tower of Hanoi puzzle is 2ⁿ − 1, where n is the number of disks. For the Agile Team the tasks for which all members agree will stay at the bottom. The lower the task lies, the more confident team is.

Benefits of White Elephant Sizing

Fast and engaging: Ditch the long estimation meetings! White Elephant is quick, taking around 30 minutes for a typical backlog. The game format keeps everyone engaged and participating.
Collective wisdom: Individual biases are minimized as each player contributes their perspective, leading to a more balanced and realistic overall estimate.
Promotes discussion: Explaining your sizing choices sparks constructive conversations, uncovering potential risks and dependencies early on.
Transparency and ownership: Everyone sees the sizing decisions in real-time, fostering transparency and a sense of shared ownership over the backlog.

Conclusion

This game helps the team to estimate faster. The fact that one story at a time is introduced helps limit the amount of uncertainty. So it should also help the team feel more confident in completing their estimation work in a set period of time. But still there are few learnings like

Group user stories according to their relative size/effort.
Reach agreement on estimation quickly, if deadlock then apply above techniques to break deadlock.
Ensure that each team member has their turn to estimate and provide their reason behind estimate.
No talking among team members helps keep the interactions focused on product owner and team rather than a intra-team focus.
Apply different techniques to remove deadlock and make the estimation fun.