Magic Estimation

Magic Estimation is a gamified estimation technique that is mostly used by Agile teams during the planning of work iterations. In Magic Estimation members of the group have to place a card that represents a User story or a Product backlog item to a proper place on the game board relatively to others, unlike Planning Poker technique where players vote for a specific value. The place on the board represent the estimate, and the process is focused on getting quick consensus-based estimates in gamified manner.

Sometimes, people refer to Magic Estimation as to a group of estimation techniques were estimation is done by placing an item on a board relatively to other items, including:

• Affinity mapping
• Swimlane sizing
• Bucket sizing / Bucket system
• Relative estimation
• Silent grouping

Process

Rationale

Magic Estimation allows all the team members to speak out, contributing and committing to the estimate. It is considered as faster, more intuitive and “more relative” comparing to Planning Poker.

Game process

A Magic Estimation session usually takes place during a refinement (backlog grooming). A team needs a dedicated room for 30–60 minutes in total, approximately 5 minutes per estimation round.

Prepare game artifacts before the session:

• Cards with estimation numbers, possibly cards used for Planning Poker games;
  • usually, Story Points are used for estimation values, like the Fibonacci scale (agile) numbers (0, 1, 2, 3, 5, 13…);
  • consider using cards with T-Shirt sizes (XXS, XS, S, L, XL, XXL).
• Cards with Product backlog items

Game preparation process:

• Spread the estimation cards next to each other on a board or on the ground;
• Add the question mark card at the end;
• The Product Owner explains the product’s vision and talks through the content of the product backlog;
• The team agrees on the PBI that will be used as the reference. Usually, it is the 1 Story Point PBI that is clear to everyone;
• The PBI cards are spread among the team so that every participant has a unique set of cards.

Estimation process:

• The first game round starts with each participant getting familiar with their own PBIs;
• PBIs are placed in the buckets or simply next to the estimation values based on the complexity in complete silence;
• In case there is no certainty about the PBI details, the question mark is selected;
• When all PBIs have been placed, the corresponding estimation numbers are written on the PBI card;
• The PBIs under the question mark are discussed by the team and clarified by the Product Owner. After this they are divided among the team members and estimated again;
• The second game round starts with a silent re-evaluating of all the PBIs positions. If you think that a PBI has been estimated wrongly, change its position to the correct one and write the new estimate on the card;
• The following rounds might take place where participants change PBIs positions again, but it’s recommended to have up to 3 rounds in total;

Finalizing estimates:

• PBIs that have kept their positions (that have only 1 estimation record) are clear, the estimate written on the card is final;
• PBIs with estimates changed only once and slightly (e.g. 1->2 or 5->3 Story Points) are usually considered as clear and the bigger estimated is selected as the final one;
• All the other PBIs are discussed until the consensus is reached and the team agrees on the final estimate;
• The game is finished when all the participants agree with the final estimates.

The result: The scope for the next sprint or the entire Product Backlog has been estimated based on team’s velocity; team members have discussed details of the user stories and are on the same page in understanding their complexity; the necessary amount of sprints can be calculated.

Online game process

The process for remote teams is similar to the in-room one, but it requires digital collaborative environment. Various online whiteboard solutions or dedicated software, like Magic Estimations for Jira, are used.

Affinity sizing

Affinity Mapping or Affinity Sizing is a variant of Magic Estimation

The main difference is in assigning Story Point values after placing the PBI cards on the estimation board:

• place all the PBI cards horizontally on the estimation board;
• start arranging the cards by their size or complexity together with the team in complete silence: the largest stories are moved to the right, the smallest - to the left;
• review the result, make final adjustments to the order after discussing details of the stories without a consensus on the position;
• add Story Points values to the board and assign them to the groups of the user stories.

Benefits

Speed. It's considered as a fast estimation technique for quick estimation of a big number of PBI

Intuitiveness. There are no rules, only one principle of moving PBIs around the board based on their size/complexity, unlike Planning Poker

Relativeness. There is no need to understand what a Story Point is

Involvement. This is a group exercise and everyone can contribute to the estimates.

Discussion facilitation. In order to finalise estimates, teams usually go through discussion to reach consensus, getting better understanding of user stories.

See also

• Planning Poker
• Fibonacci scale (agile)

External links

• Magic Estimations for Jira A free Jira app for Magic Estimation sizing.

This article "Magic Estimation" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Magic Estimation. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

📰 Article(s) of the same category(ies)

• Crystal Clear (software development)
• Certified Scrum Master (CSM)
• Dojo Delivery Agility
• Qentelli
• Devbridge Group
• Principal software engineer
• CycloneDX

---