Is Planning poker a waste of team time?

Team O'clock has been actively supporting agile meetings for the past 5+ years. In that period we've seen Team O'clock grow alongside the agile meetings and methodologies used. The debate on planning poker value has been a constant complaint through all these years - and way more before Team O'clock's history.

In the following article, we will cover the specific topic; how valuable or not planning poker is.

Let's dive right in.

Feedback Team O'clock has received, arguments against planning poker

In this section, you will find the feedback points Team O'clock has received with more explanation on what each issue highlights and additional examples to help you identify similar behaviors in your teams.

"Just doing my biweekly 1 vote. This program promotes backward processes and wastes the team's time."

This feedback indicates disengagement and disbelief in the value of planning poker. There are various assumptions that can be made on how the specific team performs the estimation session that this feedback is referring to. Assumptions like:

• During the estimation, the team quickly skims through a lot of tasks, providing hasty estimates with little to no discussion.

• Members casting votes is a checkbox in the development process with little to no effect on the actual development cycle.

• The team is performing biweekly estimate sessions - matching a sprint's two-week duration - as part of a textbook implementation of scrum. Based on the shared feedback, agile adoption is pretty low for the specific team as agile is a set of checkboxes and that's it.

Some indicators that showcase similar disengagement in your team might be:

1. A member constantly casts the same vote number, regardless of the task that is being estimated.

2. Little to no participation by team members when talking about a specific task prior to casting your vote.

3. No one asks questions, or a specific individual acts as a "vote compass" briefly announcing an estimation or a phrase like "this is pretty easy" prior to actual voting.

"Planning Poker is a bad practice that wastes time. Removing it entirely would be a huge productivity and transparency boost"

This feedback is accompanied by an old blog post - dating in 2014 - that mainly points to a video by the post writer on a new way of development: https://noestimates.org/blog/2014/07/vasco-duarte/

Check out the whole video for a good way of agile development. Specifically for planning poker, the key points mentioned are:

• Estimates on backlog items are a waste of time since by the time you need to work on them the situation has changed.

• Using story points as an alternative to user/customer value is a bad practice

• Using story points to predict the completion of a project is good, but the #noestimates approach is better.

Based on the video and feedback above, the assumptions on how planning poker and estimations are used are:

• Forward estimating a whole development project or backlog

• Estimations and planning poker is an extra step, done after the analysis of work - thus the wasted time.

• Story points produced on estimated tasks can be used as reliant tools to predict a team's velocity, the value offered to the end-user, or the completion of a project.

Some indicators of similar behavior in your team might be:

1. Trying to have everything estimated before you even need to. Whether for a full feature, or the majority of your backlog.

2. Separating the analysis and the team discussion from actual estimates. e.g. Having the planning poker session without any discussion or questions from the team since a few members have already run the analysis for the whole team.

3. Referencing story points and velocity as central pieces in your development process.

"Encourages pointless and inefficient processes like Planning Poker, Story Pointing, and really horrid suggestions that take time away from creating accurate projections and communicating with the team. It's actually creating problems. It wastes the engineers and the product owner's time."

This is another feedback that Team O'clock has received regarding planning poker. The assumptions on how the team works based on this feedback follow the same patterns already mentioned above.

Indicators that you might be doing it wrong: A summary

Having talked about the negative feedback around planning poker and possible causes of it, let's see the summary of indicators that can cause a wrong usage:

1. No analysis/no discussion: The team is requested to make estimations on tasks with no information shared and no way to get additional analysis over a task.

2. A corner case of no analysis/no discussion is when a senior or junior team member is tasked to make an estimate with no involvement from the rest of the team.

3. Discussion yet little team engagement: In cases where the same few members are talking during an estimation session means that the rest of the team is disengaged or uninterested. The purpose of a discussion during an estimation session is knowledge sharing and team alignment.

4. "Groundhog day", re-iterating on estimated tasks

   : This is the case where the team has to revisit a task estimation days after it was initially estimated. Although this indicator is not severe, it means that your team has wasted time estimating a task when it was needed.

5. "All our backlog has estimates! 👍": As shared already, having a fully estimated backlog means that you will have to re-estimate once implementation time comes, due to changes introduced by intermediate tasks.

6. Estimate a whole project before implementation starts: That's a subcase of wasteful estimates, as the implementation of the initial tasks might have an impact on the effort of upcoming tasks.

How to fix planning poker for your team?

This section holds some ways your team can calibrate estimation sessions to maximize the benefits for the whole team.

Follow the fundamentals of a good estimation session

Planning poker is an estimation tool for agile teams. As with all tools, it has a specific purpose and a way to be used. The fundamentals of planning poker are there for a reason and should always be followed, those are:

• Planning poker is a gamified way that a team uses to guess the effort of tasks they will need to build

• Planning poker is introducing cards for voting to avoid bias between team members.

• The planning poker estimate (Story points) is based on the input of the entire group

• As team members reveal their votes, they have a discussion to reach a consensus on the final estimate.

Sources referenced for planning poker fundamentals: Atlassian - Scrum poker • Asana - Planning poker • Scrum.org - Story Points are not the problem

Ask questions during an estimation session

The purpose of an estimation session is team alignment, knowledge sharing, and syncing on the approach to handle incoming work. On that basis, each team member needs to understand the full scope of the estimated task by:

• Asking clarification questions to all the participants and the facilitator

• Sharing own assumptions for validation or invalidation by the team.

Team agreement on what the final estimate of a task means

As shared already, an estimate is not a contract but a perception of the effort required. Don't forget to re-share with the whole team that this estimate includes all parts of the work that need to be in place and all the team members involved in each part. e.g. for software development includes parts for design, frontend, backend, and testing work needed on a task.

Refer to previous estimates as a reference point

You can use previously estimated tasks as a way to cross-check your estimate and kickstart a deeper discussion on the currently analyzed task.

Can my team skip planning poker altogether?

Yes!! As the team evolves and collaborates they tend to feel more comfortable skipping planning poker. The team evolution has to do with a better understanding of:

• The tools used to build work at hand, e.g. for software development if the team knows the frameworks used and the design system at hand.

• The business around the work at hand. This means that the team is proficient in using the work they produce as they are users themselves! In the software development example, the developing team is proficient at using the tools they help build.

• Each member contributes to the whole and actively supports each other. This means that each member builds empathy for the work they build so that the next member in line can do their job more streamlined.

• Communication is needed while building work at hand so that when there is an impediment to a person's work they can ping the right colleague to quickly address that impediment.

In teams that have started working together, or don't feel comfortable with the work at hand planning poker emulates some of the bullets above during the ceremony. In that sense, performing planning poker how it is meant to be helps the team mature.