User:Anton Tech-5/sandbox

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

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

Prepare game artefacts:

• Sheets with the estimation numbers (Story Points), like the Fibonacci scale (agile) numbers (0, 1, 2, 3, 5, 13…), T-Shirt sizes (XXS, XS, S, L, XL, XXL) or any other

• Markers, pens, pencils

• Product backlog item written on small cards or printed

Game preparations:

• Spread the planning poker cards next to each other on the ground with the question mark at the end;

• The Product Owner talks through the vision of the product and explains the contents of the product backlog;

• Developers selects the PBI that will be used as the reference. For example, PBI X will be set as the five-pointer, all the other PBI’s should be related to this story. The selected PBI must be clear to everyone;

• If required, the Scrum Master should explain that a story point is a combination of complexity, repetition, and risk;

• The PBI cards are divided among the group. Every team member has a unique set of PBI’s.

The estimation process:

• Round one starts and everyone studies his/her PBI cards and puts them by the number of story points they think suits best the complexity. This is done in silence, no discussions are allowed;

• If someone doesn’t know what is meant with a PBI, it is placed at the question mark;

• When all PBI’s have been estimated, the number is written on the PBI card;

• The PBI’s placed at the question mark are clarified by the Product Owner and discussed within the group until the intention is clear. After this they are divided amongst the group and placed at the number of story points they think is most suitable;

• In round two, which is again done in silence, everyone can check all the cards that are now on the ground at a Fibonacci number. When someone thinks a PBI should get another estimate, he simply picks it up and replaces it. This round continues when everyone has checked all the PBI’s;

• The PBI’s that haven’t been changed are probably clear to everyone and are handed over to the Product Owner;

• The PBI’s that changed slightly (e.g. from 2 till 3 story points) are also given to the Product Owner. Remember, the intention is to estimate an entire backlog, these minor changes aren’t relevant at this level;

• In the same round, PBI’s can only be changed once. You can do as many rounds as you want, just remember to write the story point number at the cards after every round. I often use three rounds in total;

• PBI’s that have been changed a lot is discussed centrally until there is consensus on the number of story points;

• The exercise is finished when all the PBI’s are placed at a story point number and everyone agrees with the final result.

The result: The entire Product Backlog now has been estimated in story points and based on the velocity of the team; the necessary amount of sprints can be calculated. This is, of course, a rough estimate, but it gives you an indication of the size of the Product Backlog.

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.

Start by reading out each User Story to the entire team. The moderator then asks to arrange the stories horizontally on a wall in order of size, without talking. The team places the largest stories on the left and the smallest stories on the right. This only takes a few minutes. The moderator then gives a final opportunity to make adjustments to the ordering, again without talking.

The moderator then places Story Points values above the list of stories. He asks the team to group the user stories around the nearest number.

Benefits

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

• Intuitiveness. There are no rules unlike, 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.

Category:Agile software development Category:Software project management