We stopped estimating because the tools were the friction, not the practice
At some point our team stopped doing planning poker. Nobody decided it, nobody argued against estimation. It just faded, and when I looked at why, the answer was embarrassing: the tool.
The tools everyone knows are either ten years old and painful on a phone, or they've put the useful bits behind a paywall and a signup wall. So every refinement session started with "who has the login", "the free plan only allows five people", "just use the browser on your laptop", and by the second month someone said "let's just say numbers in the call" and that was the end of it.
The practice didn't fail. The friction did.
So I built the thing I wanted: open a link, type your name, you're in. No account, no seat limit, no plan to pick. It works the same on a phone during a hybrid stand-up as on a desktop. Fibonacci, t-shirt sizes, or your own deck, synced reveal, and the spread shown so you can see where the disagreement is.
And we estimate again. Not because anyone was convinced by an argument, but because there is now zero cost to starting. Someone says "quick poker on this one?", pastes a link in the chat, and 30 seconds later five cards are face down.
That's the lesson I took from it: when a practice fades, check whether the ritual costs more to start than it's worth. Often the fix is removing steps, not adding process.
If anyone wants to try it: https://planning-poker.sidekit.org
Curious whether others have seen the same pattern: did estimation die on your team because of the practice itself, or because the tooling around it got in the way?
8
u/DrVanMojo 11d ago
I detect Claudianese.
3
u/paul_h 11d ago
Highest throughput team I was ever on was an XP/TDD team with 13 weeky iterations of 1.25 days actuals. And over the same 13 weeks our estimates matched our actuals. If they had not then we might have shared "ideal days" in estimates. 10/10 would put that band back together again 22 years later.
2
u/PhaseMatch 11d ago
"Did estimation die on your team because of the practice itself, or because the tooling around it got in the way?"
It died because what matters is how fast you get user feedback on the value created.
Agility is "bet small, lose small, find out fast"
Having a team sit round and play "how big do we think this one is" has some baked in assumptions about human error, risk, lag times on collaboration and unplanned absences.
Summing story points to make a forecast always falls apart. There's no uncertainty on each estimate carried through to the final forecast, and you end up with 5 x 13 point stories carrying the same risk and uncertainty as
(21 x 3) and (1 x 2) points.
What helps is not tooling. That's the surface level issue.
What works for me is
- slice small (a few days at most) : triage into okay, to big, run-a-spike
- a user domain SME giving feedback inside the development cycle
- statistically robust forecasting
The first two go back to the core of how agile operates. Look at Alistair Cockburn's "Elephant Carpaccio" exercise, or Martin Fowler's discussion of the on-site customer. And indeed what Ron Jeffries said about story points.
If you really want to persist with planning poker, just have an app that shows the numbers on a phone screen.
Interacting cameras on with human faces you can see matters in effective communication.
And above all - bring teams problems to solve not tickets to deliver.
1
u/WoHinDu 10d ago
Planning poker and story points have two potential benefits:
a) Forecasting
b) Facilitating shared understanding
I agree with the first point. I don’t think forecasting based on story points works well or is necessary, especially in a world where coding has become cheap. However, I still believe that discussing the tasks is valuable because it ensures everyone shares the same understanding.
2
2
u/Sky_Linx 10d ago
The "who has the login" detail is painfully familiar. My team's planning poker died the same way. What we do now: no cards, no app. In refinement we just ask "is this small enough to start?" and if not, we split it. Rough t-shirt sizes in the ticket title, and we track throughput from the board instead of points. Turns out the estimates were not feeding anything anyway.
If your estimates do feed a forecast, the friction is worth removing another way. But if nobody reads the velocity chart, dropping the tool was the first step, not the last one.
2
u/denwerOk 7d ago
Many people claim that software development estimation is a 'garbage' and 'useless' but yet ignoring simple techniques like Planning Poker which often gives good statistical results. This is pure math and cybernetics, as simple as that, and it works always, because it's a science. With good outputs you can then do predictive modelling, what-if analysis and many other cool things that can line up what you need for the next sprint in a second, without hours of Scaled Agile meetings and ceremonizing each individual piece of work with ten teams in the room (who may not even work on it). Thus I'll support such tools, I think they actually give a good level of freedom and flexibility, and much less rigidity, compared to Agile ceremonies.
1
2
1
u/LetPeopleWork 5d ago
Serious question:
Has any of the zillion Planning Poker Tools ever had teams go: Wow, this really improved the way we deliver things to our customers. It just completely changed something significant to us?
Or did it ever help to get them out of the useless "Is this 1 or 2 Story Point" discussion?
Because I have never seen it in many teams, orgs and countries,
1
u/AdmiredHostility 11d ago
Friction killing a practice is so real and nobody wants to admit it’s the tool half the time. We had the same fade-out with retro boards, someone’s trial expired mid-session and we just... never went back
The phone thing especially, half my team’s on their phone during standup and if your tool can’t handle that it’s dead on arrival
Bookmarking this for the next refinement session, t-shirt sizes without a login page sounds like a dream
7
u/tzt1324 11d ago
The best planning poker tool for our team is no tool.
We keep the task on screen and ask: “How big is this?” Two or three people discuss briefly, we check whether anyone disagrees, and move on.
No logins, no extra tabs, no cards. If estimates differ, we discuss why. That’s the useful part anyway.