Long Suciu has coached hundreds of agile teams across organizations like Gartner, Freeletics, and Vistaprint. In this segment of his conversation with Patrycja Radwanska on the Let’s Talk Operations series, he explains why his favorite first move in any transformation is the one that makes everyone the most uncomfortable: stop doing story points entirely.
The Diagnosis: Scrum Theater at Scale
Suciu has a name for what he encounters at most organizations that proudly declare themselves agile: scrum theater. The dailies are on the calendar. The retrospectives are scheduled. The refinement sessions happen with the regularity of a metronome. Story points get assigned to every ticket. And none of it is producing the outcomes anyone claims to want.
The telltale signs are not hard to spot if you know what to ask. Not the first-level question – do you use story points? – but the third and fourth-level questions that reveal whether the practice is serving a purpose or merely performing one. How much time does the team spend on pointing? Are they re-pointing tickets after work has started? Are they – and this is the one that makes Suciu’s eyebrows go up – adjusting the estimate after the work is already finished?
“Automating a bad process just makes your bad process more efficient.”
When teams are spending more time debating whether something is a 3 or a 5 than discussing how to actually build it, the practice has decoupled from its purpose. It has become ritual. And ritual, when it consumes time that could be spent on substance, is waste.
The Prescription: Just Stop
The move itself is deceptively simple. Suciu tells the team: let’s not do story points anymore. The reaction is predictable and, by his own admission, something he rather enjoys watching. Teams that have been pointing tickets for 10 or 15 years experience a combination of confusion, mild panic, and something that borders on existential dread.
The objections come fast. How will we know velocity? How will we estimate capacity? How will we plan sprints? Suciu’s response is to turn those questions back on the team. Are you actually tracking velocity? Where is it tracked? And – the one that usually ends the argument – is anyone actually using that velocity number to make a decision?
Most of the time, the answer is no. The velocity chart exists. Nobody looks at it. Nobody changes anything based on what it says. The practice was generating a number that went into a chart that went into a dashboard that nobody opened. The overhead of producing it, however, was very real: hours of refinement sessions, arguments over relative sizing, and the particularly insidious habit of pointing tickets that are already understood well enough to build.
What Happens When the Practice Disappears
The surprising thing – or perhaps the not-at-all-surprising thing, depending on your level of cynicism about organizational ritual – is what replaces story points when they are removed. The conversations do not stop. They improve.
Without the crutch of a numerical abstraction, teams are forced to talk about the actual work. How would we build this? Can we break it down? How big do we think each piece is? These are the questions that story points were originally supposed to facilitate, and that they had quietly replaced. The team was doing the ceremony of estimation without doing the thinking that estimation was meant to provoke.
Suciu finds that when the practice is dropped and teams repeatedly have these direct conversations, the quality of the discussion increases. Tickets get smaller naturally – not because someone imposed a rule about maximum story point values, but because breaking work into smaller pieces is the obvious answer to the question “how would we actually do this?” The right-sized epics with the right number of stories emerge organically from the conversation, not from a pointing exercise.
“You’re able to bring the conversations within the team to the things that actually matter, which is how might we design this feature? How might we develop this feature?”
The Deeper Pattern: Questioning Inherited Practices
Story points are the sharpest example, but the principle extends to every inherited practice Suciu encounters. Retrospectives where the same action items appear for seven consecutive sprints with no one taking ownership. Grooming sessions that exist because they have always existed. Processes introduced five managers ago that persist because team turnover means nobody remembers why they were created in the first place.
Suciu’s approach is not to arrive with a checklist of practices to implement. It is to ask three questions about the ones that already exist. First: what are the top things preventing this team from moving work forward? Second: which practices might be contributing to that problem? Third – and this is the one most consultants skip – which practices are not worth improving and should simply be eliminated?
The shelf life of assumptions, he observes, has gotten dramatically shorter. Something that was a perfectly reasonable practice six months ago may have no validity today. The teams that thrive are the ones willing to examine their own habits with the same rigor they apply to their code. The ones that stagnate are the ones where nobody has asked “why do we still do this?” since the person who started it left the company two years ago.
For the full interview breakdown, see our complete Expert Insight with Long Suciu.
Tools Mentioned in the Interview
The following tools and platforms were referenced during this conversation.
Related Content
Scaling Product Operations Without Breaking Teams: Expert Insights with Long Suciu
Long Suciu has spent 25 years redesigning how product and engineering teams plan, prioritize, and ship. He breaks down why story points are often the first thing to cut, how a six-week quarterly planning cadence brought alignment to 30+ teams at Gartner, and why tools must reinforce behavior rather than replace it.
A Six-Week Quarterly Planning Cadence That Scales Across 30 Teams
Long Suciu built a quarterly planning process at Gartner that eliminated the chaos of ad-hoc project sponsorship. He breaks down the exact six-week cadence -- think, share, solidify -- that brought alignment to more than 30 product teams.
Power BI Dashboards That Engineering Managers Actually Use
Long Suciu built Power BI dashboards from Jira data that engineering managers actually opened every morning. He explains the design principles -- readability, daily refresh, sprint goal visibility -- that made them work, and how backlog transparency led to the most productive archiving conversations of his career.