TechEarl

Sprint Planning Jokes Every Scrum Team Has Lived

Sprint planning jokes every scrum team has lived: planning poker arguments, story points of one or hundred, capacity math, and six-sprint spikes.

Ishan Karunaratne⏱️ 4 min readUpdated
Share thisCopied
Sprint planning humor covering story point estimation, planning poker debates, capacity math that ignores meetings, and sprint goals that shift by Wednesday.

50 Sprint Planning Jokes

Sprint planning is a two-hour meeting to commit to a plan that will last six hours.

"What is the sprint goal." "Finish last sprint."

Planning poker is a structured argument with cards.

"I voted three." "I voted thirteen." We were looking at different tickets.

Every team has the developer who only votes one or one hundred.

"This is a one." It is not a one.

"Refine the backlog before planning." Nobody did.

"Capacity this sprint." Everyone has a day off nobody mentioned.

"We have 40 points of capacity." "Let's commit to 70."

Sprint planning math ignores meetings. Meetings are most of the sprint.

"This sprint will be different." It was not.

"Are the acceptance criteria clear." The ticket has no description.

"Let's pull in one more." Four hours later, still arguing about it.

The ticket marked Spike has been a spike for six sprints.

"What is a spike." An admission of ignorance with a deadline.

Every sprint starts with a clean board. The board is dirty by lunch.

"We will not take in mid-sprint work." The CEO sent an email at 9:14.

"This is dependent on the platform team." The platform team is in planning right now.

Sprint planning is the meeting where I learn what I will fail at this fortnight.

"Can you take the front-end half." The ticket is back-end only.

"Let's break this story down." Three hours later: still one story.

"It is a Fibonacci value." "I picked 17." 17 is not Fibonacci. Nobody corrects them.

The team velocity is computed by averaging the last three sprints. The last three sprints were a holiday, a hackathon, and a hotfix week.

"What does done look like for this." Silence.

"This is a quick one." The quick ones are never quick.

Sprint planning runs over. The next meeting also runs over. The day is gone.

"Anyone have concerns." Everyone has concerns. Nobody says anything.

"The PM will groom the rest after planning." The PM is the one running planning.

"I think this is closer to a five." "It's a thirteen." "You haven't looked at the codebase."

Every planning meeting includes one ticket that turns into an architecture debate.

"This affects the data model." Well, that is the rest of the meeting.

"Roll over to next sprint." It was rolled over from the sprint before.

Sprint planning ends. The sprint goal is written down. Nobody reads it again.

"Did everyone agree." Nobody disagreed. Those are different.

"Two-week sprints." The first day is planning. The last day is demo and retro. We have eight days.

Eight days minus meetings is three days.

"This sprint we are committing to a 30 percent stretch." We missed last sprint's baseline.

"Confidence level on this story." The person who has to do it: thumbs sideways.

Every sprint plan assumes nothing breaks in production. Something always breaks in production.

"We will revisit at standup." The revisit never happens.

"Anything we can carry over." All of it.

"Estimate the unknowns." That is not what an estimate is.

Sprint planning is the only meeting where being optimistic is a personality flaw.

"The QA on this is just a smoke test." No QA is just a smoke test.

"How long for the integration test setup." The person who did it last left in March.

Every sprint goal contains the word "finalize." Nothing was finalised.

"Can we leave a buffer." The buffer is what we already planned.

"We are committing." The word commit doing a lot of work in that sentence.

"What if we just plan for half." The room considers it for the first time in five years.

Sprint planning is the most accurate forecast a team will ever produce. It is wrong by Tuesday.

Why sprint planning humour keeps refining itself

Sprint planning is the meeting where a team tries to predict the next two weeks of work, and the joke is that nobody can predict the next two weeks of work. The Scrum Guide is careful about this: it says the sprint backlog is "a forecast by the developers about what functionality will be in the next Increment." A forecast, not a commitment. Every team I have ever been on heard the word "commit" anyway, and the meeting became a hostage negotiation between optimism and capacity.

The recurring beats — the planning poker argument over a one-versus-eight, the capacity math that ignores meetings, the spike that has been a spike for six sprints — are not failures of any one team. They are the structural consequence of trying to estimate creative work in finite units while leaving room for everything that estimates cannot cover: production incidents, ad-hoc requests from the CEO, the dependency on a team that is also in planning right now, the ticket that has no description. The Atlassian playbook acknowledges this; their guidance for sprint planning explicitly recommends leaving capacity for unplanned work. Almost nobody does, because committing to less feels worse than over-committing and under-delivering, even though the math is identical.

Most of what happens in the meeting is estimation theatre. The Scrum Guide is explicit that story points represent relative effort and capacity, not a contractual hour count, and yet every organisation I have worked in eventually maps points to days and days to commitments and commitments to performance reviews. Planning poker becomes a negotiation over the implied deadline rather than the implied complexity. Refinement, which is supposed to happen before the meeting, happens during the meeting, because nobody read the tickets in advance, and the two hours produce a sprint goal that the team has stopped quoting by Wednesday and forgotten by Friday. The ritual is intact. The function it was supposed to serve is not.

The humour survives because the meeting survives. Every other agile ceremony has been challenged or shortened over the last decade. The daily stand-up turned into an async message. The retrospective went monthly. The demo became a recorded video. Sprint planning stayed two hours, every two weeks, forever, because the alternative — admitting you do not know what you will be doing two weeks from now — is the one truth a quarterly roadmap cannot survive.

See also

Sources

Authoritative references this article was fact-checked against.

TagsHumorJokesSprint PlanningScrumAgileStory PointsPlanning PokerSoftware Development

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Software Systems Architect · Senior Software Engineer · Engineering Leadership

Software systems architect and senior software engineer with more than two decades designing, building, and running production software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Now a CTO, though what I write here is drawn from the full arc of that work, across architecture, engineering, and operations, not any single job.

Keep reading

Related posts