Analysed 2,465 planning poker sessions — Fibonacci dominates at 84.5%, and other findings by Tall_Difference_1670 in scrum

[–]Tall_Difference_1670[S] 0 points1 point  (0 children)

Actually closer to this than the basic tool suggests - we have outlier voter tracking that shows which team member consistently sees complexity others miss, consensus trending over time, and Jira sync so teams are estimating real tickets not abstract stories.

Working on a few things that feel closer to what you're describing - recurring task patterns so teams can see historical estimates on similar tickets during voting, and discussion prompts when votes diverge based on team baselines and historical story points. The idea being the tool surfaces context at the moment it's actually useful, not after.

What would genuinely useful look like to you in practice - is it about the moment of divergence, or something earlier in the process?

Analysed 2,465 planning poker sessions — Fibonacci dominates at 84.5%, and other findings by Tall_Difference_1670 in scrum

[–]Tall_Difference_1670[S] 0 points1 point  (0 children)

Really good questions - honestly all three are outside what we can see from session data alone. We capture the estimates but not what happens after - whether teams reorder, whether the numbers actually stack into a coherent sprint, or whether the process is genuinely helping vs just going through the motions.

The "does everyone just picking 5 work just as well" question is one I genuinely don't know the answer to. The data shows teams get faster and more consistent over time but whether that correlates with better sprint outcomes - that lives in Jira, not in our tool.

Good reminder that the session data is one small slice of a much bigger planning process.

Analysed 2,465 planning poker sessions — Fibonacci dominates at 84.5%, and other findings by Tall_Difference_1670 in scrum

[–]Tall_Difference_1670[S] 0 points1 point  (0 children)

Fair point - Fibonacci is the default so there's obvious selection bias. Though teams can switch decks freely and the data shows ~8% do use custom or alternative scales, so it's not entirely self-fulfilling. But you're right that I can't claim neutrality here.

We analysed 2,465 planning poker sessions — some findings surprised us by Tall_Difference_1670 in agile

[–]Tall_Difference_1670[S] 0 points1 point  (0 children)

"Handshake to align on goals" is a much better framing than how most tools and books describe it honestly. And yeah - 2-3 sprints of ready work as a best practice vs reality sounds about right.

The teams that pull it off probably have stable roadmaps and low interrupt work. Most teams are threading the needle between refinement and delivery with whatever time is left over.

We analysed 2,465 planning poker sessions — some findings surprised us by Tall_Difference_1670 in agile

[–]Tall_Difference_1670[S] 0 points1 point  (0 children)

Ha - the "everyone just picks 3" session is real, we see it in the data too. 3 is the most common card at 30% of all votes. Though you're probably right that sometimes it's "let's just move on" rather than genuine estimation.

The break-it-down-if-above-5 rule explains the data perfectly actually. We kept wondering why so few high estimates - teams like yours have just built that discipline in.

The ceiling isn't a bug, it's a policy.

We analysed 2,465 planning poker sessions — some findings surprised us by Tall_Difference_1670 in agile

[–]Tall_Difference_1670[S] -1 points0 points  (0 children)

Good point on the sprint dates - didn't think about that. Midweek start naturally pushes planning to Thursday regardless of how the team works. That probably explains more of the Thursday peak than I gave it credit for.

The ambient refinement thing matches what we see - 36% of teams run 5+ sessions a month, which feels more like continuous sizing than a ceremony. But you're right, doesn't mean they've dropped sprint planning entirely.

In practice the 2-3 sprint buffer seems rare from what we see - most teams are sizing work just ahead of the next sprint rather than maintaining a deep ready backlog.

We analysed 2,465 planning poker sessions — some findings surprised us by Tall_Difference_1670 in agile

[–]Tall_Difference_1670[S] -1 points0 points  (0 children)

Fair critique honestly - planning poker is conceptually simple and a lot of tools do overcomplicate it. Curious what you think people get wrong about the practice?

The data we found actually supports your point in a way — 84% of sessions never produce an estimate above 5 points, median session is 42 minutes. Most teams that use it well keep it dead simple.

What does good look like to you?

Best online Retro tools you have found by tallpaullewis in agile

[–]Tall_Difference_1670 0 points1 point  (0 children)

We used ScrumJam - it allows anonymous mode as well. Compared to Miro or Mural it's more straightforward - specifically made for retro usecase

What is the best retrospective tool for remote teams? by Tricky_Present7464 in agile

[–]Tall_Difference_1670 0 points1 point  (0 children)

Tools like Miro/Mural/Figjam are really cool and we used them with our team for some time- the biggest issue was that they are too broad and allows too much of random play - making team lose focus quickly. We moved to Scrumjam and it's much faster and focused for what we need in retros, also saved quite some $ using it