Magic Estimation Game: How to Do It Remotely

Magic Estimation can be a tough challenge if you are not sitting in a room together. With a few adjustments to the workflow, and the clever use of collaboration tools, we have managed to conduct a remote Magic Estimation. Here’s how we did it.

In this post, Merle Heidel and Tobias Maasland from inovex will discuss, in detail, the reasons why remote Magic Estimation can be used to our advantage. Afterwards, we will showcase our suggested workflow for remote Magic Estimation. The good thing: it can be set up easily and provide estimated Product Backlog Items (PBIs) as a result. Later, we look at two different remote setups:

• Remote Magic Estimation with Jira, Zapier and Trello
• Remote Magic Estimation with Azure DevOps and Miro

What is Magic Estimation?

Using Magic Estimation in Agile allows us to estimate lots of PBIs in a fairly short time. Estimating is about assessing the complexity of user stories by the development team. This act involves a variety of aspects such as risks, uncertainties, dependencies, and both the complexity as well as the volume of work that each PBI entails.

With the Magic Estimation you gain insights into your product backlog which can assist you in:

• Determining a rough estimate of the relation between individual PBIs.
• Comparing estimated costs with expected benefits.
• Enabling the Product Owner to become more efficient and effective in prioritising as well as organising the project’s backlog, both at the beginning as well as throughout a project, when new requirements arise.
• Estimating PBIs and – if necessary – redefining or removing parts thereof.
• Costing fixed-price orders.
• Managing expectations with the project’s stakeholders and thus improving communication.
• Introducing transparency in terms of complexity and uncertainties within the backlog, allowing one to take action and create spikes, adjust priority, find new solutions or break PBIs down.

The common setup

Magic Estimation is an activity which takes place during a refinement session. In its common setup, the development team would come together in a room to congregate around either a big table or in front of a large wall. Every PBI has previously been written on a sticky note or piece of paper, which is then presented to the team as a shuffled stack. Team members consider each PBI individually, ultimately placing each note into a column based on the assigned story points (SP). For example, a team member may put a PBI with 3 SPs into a column entitled: “3 Story Points“.

After the first round has concluded, the second round entails a team members moving individual PBIs to alternative columns, if the members are not satisfied with its initial positioning. The Scrum Master, or host, usually observes which PBIs are moved a lot between columns in particular and places an emphasis on them. A little discussion may take place afterwards to ensure that every assumption has been brought up. However, it is worth noting that the well-known discussion about user stories should not take place.

As you can imagine, all of this is much harder when you are not in the same room together, but with a few adjustments this process can also work remotely!

Introducing: Remote Magic Estimation

Requirements

Before you begin, you will need the following for a remote setup:

• A video conferencing software,
• A list of all PBIs to be estimated, easily formulated for everyone to understand, to avoid excessive discussions,
• A collaboration tool that enables the team to interactively sort through the PBIs,
• And finally, the following set of rules.

Preparation

Before the remote Magic Estimation session starts, ensure that all PBIs have been transferred to the collaboration tool of your choice. Our recommendations are listed at the end of this article.

The next step is to establish a grid of columns reflecting your estimation principles. PBIs are commonly valued in story points. When it comes to units of measurement for story points, adapted Fibonacci ranges or t-shirt sizes tend to suffice. Name your columns using the unit you have agreed on. For example, in one of our setups, as showcased below, we used the following columns:

• Product Backlog, 1 SP, 2 SP, 3 SP, 5 SP, 8 SP, 13 SP, 20 SP, 40 SP, 100 SP

Alternatively, you may start without any story points altogether and add them afterwards. However, you have to remember that Magic Estimation – just like Planning Poker – relies on a relative estimate. It is always important to establish a relation between PBIs. If this basis is not given, everyone interprets something else and you will fail to relate your estimate.

Especially at the beginning of the exercise, it is difficult to define the range of story points. In this case, your team can initially rank the PBIs from the smallest to the largest. With the columns not yet labeled, the PBI considered the smallest is placed into the far left column and the largest PBI into the far right. If a PBI is seen to be of the same size as another that has already been placed, simply add it to the same column.

After the second round of the activity is completed (see below for more information), the team can jointly give each column, and thus each associated card, an estimation unit, such as the Fibonacci range. In our proposed workflow, we will not go into further detail regarding this approach, as we have tested the Magic Estimation Game in projects that had already agreed on an estimation unit and with teams that had previously worked on PBIs.

To increase flexibility, you can introduce additional columns such as a Spikes or Unknown column, wherein team members may place cards they consider too hard to estimate:

• Spikes (see cyan colored lane) and Unknown (if it is really impossible to estimate, see „???“ lane)

Reference PBIs may also be sourced in advance. Especially if your team has previously worked on PBIs, you may also use previously estimated and completed stories as points of reference. To do this, you can place two to five stories under their corresponding columns to serve as an example of the story points.

The event

The event starts with a short introduction of the rules by the host. Then the host will determine a random order of team members. During the event, the host should ensure that all team members take their turn one after the other. No team member should be skipped. An exception may be made if a team member wants to miss a round because they cannot assess a PBI. In addition, the host can actively remind the team of the reference stories for estimation if there are any.

Basic Rules

Basic rule number one for this to work: No discussions!

Round 1: Rough Ordering of PBIs

Following the initially determined order of participants, each team member should do the following one at a time:

1. The first person in line takes the top PBI off the stack.
2. They talk very, very, very briefly about their assumption concerning the complexity and size of the PBI. It is important to note that discussions between team members are not allowed. Matter of fact, only the person whose turn it is, may speak.
3. They place the PBI in the column deemed appropriate. The estimate made must be exact. No intermediate values are allowed, only those that are displayed in the columns, thus a card cannot be placed inbetween.
4. Assumptions made by the participant can be recorded by the host. This makes it easier to understand the decisions made in retrospect.
5. The next team member picks up the next PBI from the top of the stack.
6. This continues until the stack of PBIs is completely worked through and all cards have been placed into columns.

First round done – take a break!

Tip: If the host notices that a team member seems indecisive or is struggling, they can remind everyone that this is only a very rough estimation and not about details. Remind the team that they will be able to rate PBIs differently at a later date if they are not satisfied with the rating of a team member.

Round 2: Re-Ordering

Resuming with the previously determined order of participants, starting with the first they:

1. Select a PBI they consider to be placed incorrectly.
2. Talk very, very briefly about why they think the PBI differs in complexity or size.
3. Put it in the column they deem appropriate.
4. It’s the next team member’s turn.
5. If a team member does not see a card that needs to be changed, the person may leave the reordering process. However, they remain in the virtual room.Optional: Add some kind of information each time a card is moved, such as a tag as a visual aid. If a card has been moved at least 3 times, discuss it in more detail.
6. Once everyone has completed the second round, the Magic Estimation Game is considered over. Now there are no cards that require moving and the team is satisfied with the order established.

Well done!

If, at the end of the game, you still have PBIs left over that could not be estimated, you will still need to clarify them. This should be done immediately with a more precise estimation approach such as Planning Poker or through a short discussion. If the discussion does not lead to a result, you can refer to the Product Owner for further clarification as, apparently, information is still missing here.

The outcome

Now you have a Magic Estimation. You get an idea of the relation between the PBIs and you gain insights into your product backlog. However, we still don’t know the hidden complexity that will emerge when the team actually goes on to work on the PBIs. We must remember that we can never know about the uncertainties we will face, besides that it is a rougher estimation than a regular estimation.

PBIs may require to be re-evaluated during a refinement session at a later point in time. This allows us to look at the aspects of complexity in more detail. However, this is a decision that the Product Owner and the development team have to make on their own.

Tip: Especially at the end of the session, when only a few team members are still moving cards around, it is both appropriate and advisable to start the discussions. Otherwise, it is important to stress that one should not discuss too much during this activity in order to get a good and fairly quick result.

Remote Magic Estimation with Jira, Zapier and Trello

For teams looking for a lightweight and simple remote solution:

Trello is a great list-making application. It is web-based and free to use. All you need to do is create an account and a board in Trello. The board’s first column should contain all PBIs to be estimated. You can write all PBIs by hand. If there are only a few PBIs, this is a quick set up.

Alternatively, if you already have an extensive backlog, you can import everything into Trello using the Zapier application. Zapier makes it possible to import data from one web app into another. To learn more about Zapier: Bulk import data into Zaps

Are you using Jira? If so, you can create a query to aggregate all your required user stories within Jira. Export the query result as an Excel file and copy/paste the content directly into a Google Sheet. You can now use Zapier through Trello to import all necessary information into your Trello board.

Add additional columns to your Trello board to reflect all of your story point units and, finally, add a column called unknown to add more flexibility. Your preparation is done. You are now ready to estimate your PBIs together with your team.

Preferably, the host shares the Trello Board via a video conferencing software and invites all team members. The above mentioned rules can be applied here as well. Each team member should take the first PBI from the stack and assign it to a story point column until the stack is empty. Afterwards you start with the second round: re-ordering.

 

 

Remote Magic Estimation with Azure DevOps and Miro

For teams looking for a solution that allows more flexibility and adaptation:

We used Miro – an online collaborative whiteboard platform – to virtually represent a large boardroom table or wall, as you would normally use in Magic Estimation.

To import the product backlog into Miro, we first created a query in Azure DevOps to source all of the required PBIs. The query was composed to return all PBIs that were neither ready nor estimated. The query dialog contains a button called „Export to CSV“ which we used to export the information.

Importing content into Miro is super fast and easy. For more information, click on the following link: Sticky Notes. You just have to open the CSV file and select all the rows you want to be transferred. Now you just have to copy and paste them, using Ctrl+V, into the Miro board. Miro will automatically create a sticky note for each row that is imported. Then you have successfully transferred your PBIs into Miro!

With a few minor adjustments and some structuring, the digital whiteboard is ready for your team. Using Miro, you have a lot of control and many ways to make it work for you.

If you do opt for this approach, you are very dependent on both the team as well as the host to know their way around how Miro works in order to get a good result. For teams that are completely new to agile estimates, it’s advisable to use Trello due to its rigid nature. There are also a lot of other digital whiteboards out in the wild that you can use. For instance, you might want to check out the Google Jamboard or Mural.co as an alternative to Miro, in case you are still looking.

Personally, we were both happy as well as successful with Trello and Miro. Feel free to give us your feedback on the remote approach to the Magic Estimation game we have presented. Also – which collaborative tools do you use?

 

Merle Heidel, Scrum Master bei inovex, unterstützt die zielgerichtete Erarbeitung von wertvollen Produkten. Ihr Fokus liegt dabei in der Förderung einer agilen Kultur mit dem Einsatz agiler Methoden und Praktiken.

 

Tobias Maasland, Scrum Master und Agile Coach, unterstützt Teams wie auch Organisationen dabei, aus traditionellen Herangehensweisen ins Agile Mindset zu kommen. Für schon etablierte Teams und Organisationen coacht er schwerpunkt basiert, on-site wie auch remote.

 

inovex arbeitet grundlegend verteilt und Remote.