Planning Poker that doesn't slow you down!

Planning Poker

Are you wasting your time on outdated tools?

Users of existing planning poker tools feel they slow down the estimation process. An insight we noticed when performing user research in the field. Today the first teams are breaking away from outdated methods. This post covers how current tools slow teams down and how SmartGuess helps teams move back to the fast track.

What exactly are users experiencing?

There are many sources online where users share their experiences about current planning poker estimation tools. Here is what users are saying:

  • "My teams are struggling with estimation tools. We have tried everything with little to no success."
  • "I don't have a favorite online tool because I haven't found a tool that doesn't slow the process down."
  • "..we have abandoned this idea. We did not find any solution. I mean, there were no third-party tools that worked out!"

Hearing this feedback from multiple sources, it's vital to understand how current solutions work to tackle the problem better.

Understanding the job at hand is the key

If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions, Albert Einstein

Understanding the sprint planning job is the key to finding a better way for teams to run Planning Poker during story discussion. So let's dive in and understand what happens during Sprint planning and map out the process step by step. Let's start with how Sprint planning plays out when using physical Planning Poker cards:

Observation: Only a tiny part of sprint planning is estimating

The picture shows the estimation steps are only four, the green cards. In total, there are thirty cards, which means only a small part, 13% of the whole process is about estimation. This makes sense because the key outcomes of sprint planning are building shared understanding and making good decisions on how to proceed.

What follows is that good tools keep this in mind allowing teams to focus on the most critical outcomes rather than taking center stage and getting in the way.

Let's walk through Sprint planning using a tool such as Jira and physical Planning Poker cards, to understand the baseline.

Sprint planning starts

When sprint planning starts, the team shares a screen showing the backlog, allowing them to move through the backlog, discussing stories in priority order.

Discussing a story

When discussing a story, before estimating, the team needs sufficient clarity. In general, the discussion is about three things:

  1. Value - is value for the user clear?
  2. Feasibility - is clarity on story implementation technology-wise?
  3. Usability - is clarity on design and user experience?

Key actions noted

The story is kept up to date during the discussion by recording key decisions and action items. Once sufficient clarity is in place, the team moves into estimating.

Estimation

With everyone at the same place, with physical planning poker cards in hand, it's easy to run estimation using the Planning Poker method:

  1. Each team member decides on an estimate
  2. Team members share their estimates
  3. Discussion on differences takes place - moving back into updating the story - if the discussion calls for it
  4. The team decides on an estimate
  5. Updates the story point value

The meeting continues, once all stories have been discussed and estimated, team members break the stories down as needed, in line with the Scrum guide - How will the chosen work get done?

Where does this process break down?

Overall, this process works quite well. However, it breaks down when team members can't share the same room and try using tools vastly complicating the workflow, as the following user explains:

"My teams have been struggling with estimation tools, especially remotely. We've tried everything from pointing on fingers to cards to post-it notes to third-party tools with little to no success."

Let's look into the job steps for current tools in comparison.

How first-generation Planning Poker tools are wasting your time

We can see where things get complicated by mapping out the job steps using the same approach. Note that 'Step 1 - Making stories ready for planning' is the same. However, 'Step 2 - Setup the Planning Poker tool' is where things get complicated.

#1. Problem - Setup the planning session

You need to set up an 'estimation game' using first-generation tools. Some tools have as many as eight different fields just to get started.

#2. Problem - Create and manage a copy of your backlog

With the first-generation tools, users are making a copy of the stories they will be covering. Once a copy is in place, they need to manage two lists; the backlog and its partial copy, the 'estimation backlog.'

#3. Problem - Found missing a story? Extra work for you!

What happens when you identify a missing story? Frequently this occurs when preparing or during sprint planning. When managing two lists, you need to first create the story in the backlog and then add it to the estimation backlog.

#4. Problem - Sharing the 'estimation backlog' with the team

Some tools need you to fill in team members' emails to share - as if calendar apps or Slack didn't exist.

#5. Problems - Stories in the 'estimation backlog' are missing info

Once teams open the 'estimation backlog' and start estimating a story, key information is often missing. This is because these stories present only a limited set of information. Meaning you can't quickly bring up an important attachment, comment, etc. You first need to open the Jira issue.

#6. Problem - Updating stories in the 'estimation backlog' is further away

Using the 'estimation backlog' and discussing a story. When the team needs to update a story, you can't easily do that. This is because stories in the 'estimation backlog' present only a limited set of actions. Meaning you first need to open the Jira issue to update the story.

#.7 Problem - Updating story points in Jira isn't a simple action anymore

Saving estimates is more complicated. Using tools not integrated with Jira means you need to update all issues you covered manually. Many tools with Jira integration have an overly complex way of saving estimates. See the picture

Comparing the two approaches side by side

There is a stark difference between the two, mainly because of two things. First, you need to set up the first-generation tool every time you use it. Secondly, you need to move back and forth between Jira and the planning poker tool during planning to get things done.

What kind of solution works better?

Seeing the Sprint planning process mapped out side by side, it is clear how the first-generation tools recreate parts of Jira, introducing complexities and extra work for users. Smart Guess takes a different approach and builds on Jira's strengths. Adding functionality teams are missing to run remote Planning Poker estimation effectively within the Jira backlog.

As can be seen by comparing the three approaches below, Smart Guess takes the same approach as planning poker with physical cards:

Cut your sprint planning estimation process in half

Moving away from existing tools means:

  1. No 'estimation game' setup - just get your backlog ready for planning, no time spent creating and managing an 'estimation backlog.'
  2. Planning and estimation solely from the Jira backlog - allowing the team discussion to flow naturally between story discussion, estimation, and updating stories
  3. Run remote planning poker as if co-located

It also means teams now use the best tool for Sprint Planning - the Jira backlog! Here is a short video showing how Smart Guess for Planning Poker works:

shape1shape2

Share your thoughts:

Recent Posts