Different teams use different methods and techniques to estimate their backlog. Regardless, estimation as a ceremony is said to be difficult for all. Whether you are a product manager, project manager, or software developer, it’s often said to be one of the most challenging aspects of the job.
When you start estimating you may encounter some additional challenges; you might be new to estimations, or for example when your team has to move to a remote setup in a day—all of a sudden you have to adjust to work and collaborate online.
As a Product Owner or Team Manager, you want to make sure the estimation you run enables discussion and maintains the balance between the estimating process speed and required accuracy. However, if you are a Scrum Master, you’re in the hunt for tools that enable realistic commitment and collaboration by providing flexible and proven ways of estimating and planning.
Agile Teams can adopt numerous estimation methods depending on how experienced with estimation a team is and help achieve the estimates as accurately. And whatever method you use you have to make sure it serves your team, your goals, and the way you operate.
Here, I want to focus on Magic Estimation Games and provide some tips on how to estimate using this method to make the most of it, give a step by step guide on how to play it in Jira, and get your backlog ready for planning.
What is Magic Estimation?
Magic Estimation Game is a relative estimation method, also known as ‘silent grouping’ or ‘affinity estimating’. It’s a Scrum team exercise that focuses on estimating product backlog with story points in a reasonably limited amount of time. It consists of estimating tasks or user stories, not separately, but by comparing or grouping those items of equivalent difficulty or effort. No matter if you work in a team that is new to estimation or with greater experience in estimating and want to speed up the estimation process.
This method is perfect for making pretty rough, relative estimations of many issues or a small number of issues with detailed discussion.
Additionally, it is considered fast, easy, and intuitive as the team doesn’t need to think of estimation values, but only compare one item to another.
Magic Estimation is recognized as an estimation method with a low level of issue discussion comparing to standard Planning Poker. Still, as a team, you can easily adjust it to the way you run your sessions. This approach is usually much quicker and more comfortable than estimating your Product Backlog with Planning Poker. The downside is, it is less accurate compared to Planning Poker, so it is best recommended for high-level initial estimation of an entire backlog, for example at the start of a project.
To sum up choose Magic Estimation if:
- your team has a low to moderate experience in Story Points estimation,
- you want to make quick and rough estimations of many issues,
- you want to run a detailed discussion for a small number of issues.
Also, estimation, in general, can get more challenging if your team is distributed or working remotely. However, because Magic Estimation is visual and interactive, it makes it easier and a better solution for teams who have to work and collaborate online instead. Due to its visual nature, participants can see the tasks or issues to estimate relative to one another. They can compare items or issues by placing them in their respective columns. There are smart tools out there that can support the estimation workflow and make the estimation a great experience.
Magic Estimation setup in colocated teams
Magic Estimation is an exercise that takes place during a refinement. Traditionally, the Dev Team and the Product Owner would gather around a physical board, or a table split into columns with Fibonacci or T-shirt sizes values. All user stories to be estimated are written on sticky notes or printed out on pieces of paper. Those user stories are then shuffled on the same board or table.
The general approach is that team members take turns, and each of them can move one card at a time and assign it to the column with the relevant estimate. Then, the next team member can either place the next item from the stack of cards in the column with the relevant estimate or move the card placed by another team member to a different column if he or she estimates the item differently. The process continues until all items from the stack are assigned an estimate. At this point, no discussion is taking place.
Some items will be moved between columns, and some others will stay in the column they were initially placed. During the session, the moderator keeps track of the items that were moved several times to be discussed in the next step of the estimation. The team can review and move individual items to alternative columns once the consensus is reached. This is when a short discussion takes place to make sure various opinions are taken into account.
How to run Magic Estimation remotely in Jira
1. Install Whiteboards
To get started install Whiteboards for Jira from the Atlassian Marketplace to get started with Magic Estimation.
2. Choose the template
Once installed, create your first board. You can choose a dedicated template to have a ready Magic Estimation setup populated on your board automatically.
3. Configure your Magic Estimation Template
Here you configure your template for the estimation:
- set the values for estimation (Fibonacci, T-shirt sizes, etc.),
- choose the scope of the session – board, JQL,
- pick a board, where you would like to perform the estimation and the issues to be estimated.
Once you save all settings, give your board a name and you’ll be taken to the configured whiteboard.
4. Run your session
You now have a whiteboard with a set of issues to estimate (that you selected during the setup) and configured component “Issue table” – configured for selected values. It is beneficial as it allows you to have a one or two-dimensional table where values are automatically synchronized with Jira.
All you need to get started is to invite your team to the board. Then collaborate, drag and drop issues to the relevant column and run your Magic Estimation session as you would in the colocated setup.
However, to identify items to be discussed, the moderator should keep track of those items that were moved between columns several times. You can designate a ‘to be discussed’ area where the moderator will drop all items without consensus.
Alternatively, a moderator or a team member draws a dot on the card every time it’s moved between the columns. The card with the highest number of dots can then be discussed to gather different team members’ opinions and finally reach a consensus.
5. Saving the estimates
You can run your estimation session and once you reach the consensus with the team, synchronize the results automatically with your fields in Jira. No duplicate work needed- pure native Jira experience.
Why Whiteboards over other tools?
There are many tools that can support all sorts of teams in their daily routines. If you work in a remote or co-located team looking for a flexible estimation and planning solution offering various estimation methods, try Agile Poker for Jira.
This app is something more than just planning. It enables Scrum Teams to estimate the backlog accurately and conveniently in four ways. If your team is working in the same time zone, go for the Interactive mode to assign story points together. For remote teams, use the Asynchronous session to reach the consensus at your teammates’ own pace. To quickly estimate a large batch of Jira issues, choose the Relative estimation mode or Bucket Sizing.
If, on the other hand, you want to get your team together in one collaborative online space where you can brainstorm, plan or estimate there are many tools out there to choose the one that serves your team’s needs best. Below I compare Whiteboards with other similar apps available on the Atlassian Marketplace.
Try Whiteboards with your team and start a truly effective and smart work online with Whiteboards for Jira. This complete solution will support your estimation, planning, prioritization, and retrospective sessions.