“I’m gonna say it. I don’t care about sprint deadlines.” That LinkedIn post drew more than a hundred comments — velocity dismissed as “standard scrum junk,” defenders pointing out that velocity is a planning tool, not a KPI, and everyone talking past each other. Underneath the heat sits an old, unresolved question: the sprint commitment vs forecast distinction. Get it wrong and every sprint ends in an argument about a promise nobody remembers making. Get it right and the deadline stops being the enemy.

Where the resentment comes from

Nobody resents a forecast they helped build. Teams resent commitments manufactured from numbers no one checked: last quarter’s velocity applied to this quarter’s roster, planning at 100% of theoretical capacity, a scope list assembled before anyone looked at the calendar. When a forecast built on fiction is treated as a blood oath, missing it feels inevitable — and the rational response is exactly the one in that LinkedIn thread: stop caring.

The anti-deadline crowd is right about the disease. Their prescription — abandon the discipline — just trades one failure mode for another: a sprint with no stated outcome, where stakeholders learn nothing at planning and trust erodes from the other direction.

What Scrum actually asks you to commit to

The Scrum Guide settled this in 2011, and most organizations never noticed. The word “commit” was deliberately replaced: teams forecast the work they select for a sprint. Commitment didn’t disappear — it moved. Since the 2020 Guide, each artifact carries one: the Product Backlog has the Product Goal, the Increment has the Definition of Done, and the Sprint Backlog has the Sprint Goal.

Read that carefully and the deadline fight dissolves. Scope is a forecast. The goal is the commitment. A team that finishes nine of eleven tickets but delivers the Sprint Goal kept its promise. A team that finishes all eleven but missed the outcome kept a list.

The version that works in practice

A forecast is only as honest as the capacity math under it. The sequence that holds up:

1. Compute real capacity first. Actual roster, actual calendar: leave, holidays, meetings, part-time allocations, support rotations. Not six people times ten days.
2. Forecast scope that fits that capacity. Whether you size in points or hours matters less than checking the total against the calendar — the story points vs hours debate is a sideshow next to an unchecked roster.
3. Commit to one Sprint Goal. A single outcome the forecast serves, negotiated while capacity is on screen.
4. Record all three. Capacity, forecast, goal — written down where the team and stakeholders can see them at the review. A sprint planning checklist keeps the sequence from being skipped under time pressure.

Run planning this way and the deadline conversation changes shape. Stakeholders stop hearing “we promise these eleven tickets” and start hearing “here’s the outcome we’re committing to, and here’s the forecast behind it — built on who is actually here.” Our full sprint planning guide walks the whole ceremony end to end.

Making the forecast honest in Jira

The failure point is rarely philosophy — it’s that real capacity is invisible at the moment of planning. Jira shows a backlog and a board; it doesn’t show that Priya is out Thursday–Friday or that half of Marcus belongs to another project. DiViM’s sprint planning and capacity app for Jira puts per-person availability, allocation, and days off on the planning screen, so the forecast is checked against the roster as you build the sprint — and the recorded commitment survives to the review. Pair it with Backlog Refinement for Jira so the stories entering the forecast are already sized and ready, not estimated live in the meeting.

The takeaway

The “no deadlines” crowd has diagnosed something real: commitments extracted from unexamined numbers are a trust-destruction machine. The fix isn’t caring less about dates — it’s separating the two things Scrum already separated fifteen years ago. Forecast the scope from capacity you actually verified. Commit to the goal. Do both in writing, and the sprint deadline goes back to being what it was supposed to be: a cadence, not a courtroom.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio