Our sprints are two weeks long. Sprint planning is booked for five hours. It takes about eight.
Eight developers, all remote, one long call. We start in the morning, we break for lunch, we come back, and somewhere in the late afternoon we have a sprint backlog and nobody has any brain left. There's a word for the state everyone is in by then — へとへと (hetoheto), wrung out — and it's become the normal way to end planning day. The rest of that day is gone. Nobody is writing code after that meeting.
Here's the part that stings. The Scrum Guide caps Sprint Planning at eight hours, and that cap is for a one-month Sprint. For shorter Sprints, it says, the event is usually shorter. Ours is half a month and we use the full month's budget.
The obvious fix doesn't work
The first thing you'd try is the thing we tried: just go faster. Timebox it hard, stop the long discussions, take the number that's on the table and move on.
When we do that, the meeting ends on time and the sprint gets worse. Items we sized quickly turn out to have a dependency nobody asked about. Work that was "basically done, just needs testing" isn't. By the middle of the sprint the board and reality have drifted apart far enough that we're re-planning in the stand-up, which is its own problem.
So the eight hours aren't pure waste. They're buying something real: shared understanding, caught dependencies, a plan that mostly survives contact. The choice looks like paying in meeting hours or paying in mid-sprint chaos, and for a long time I assumed those were the only two options.
What the eight hours are actually made of
They aren't estimating hours. That's the thing I got wrong for years.
If you sit and watch where the time goes, most of it is people reading a ticket carefully for the first time. Someone asks what a field means. Someone else remembers a batch job downstream. We message the product owner and wait. We look at an old table together and try to work out whether anyone still writes to it. That's analysis, and it's necessary work — it's just not planning work, and doing it with all eight people in the call is the most expensive possible way to do it.
The actual planning — picking items, sizing them, agreeing on a sprint goal — is maybe ninety minutes of the eight hours.
Once I saw it that way, the trade-off stopped looking like time versus accuracy. Here are the three things we're trying. I'll say up front that we have not fixed this.
1. Move the discovery out of the room
The Scrum Guide describes Product Backlog refinement as "an ongoing activity to add details, such as a description, order, and size" — not an event, not something with a slot. Because it has no slot, on a busy team it doesn't happen. And because it doesn't happen, planning day becomes the refinement session, with the maximum number of people in attendance.
So we gave it a slot: one hour a week, mid-sprint, top-of-backlog items only. Read the ticket, write down what's unclear, get the questions to the PO while there's still a week to answer them.
Two warnings from doing this badly first. Refinement will quietly grow to fill whatever time you give it, so it needs a harder stop than planning does. And the instinct here — strong on every Japanese team I've worked on — is to invite everyone, because nobody wants to be the person who wasn't there when something was decided. If all eight of you attend refinement, you haven't moved the meeting, you've bought a second one.
2. Give the meeting a bouncer
We wrote down what a ticket needs before it's allowed into planning. Ours fits in three lines: acceptance criteria exist, dependencies are named, and there's no open question that only someone outside the team can answer.
Worth being straight about this one: a "definition of ready" is not part of Scrum. The Scrum Guide has a Definition of Done and nothing on the input side. This is a local rule we invented because the alternative was discovering the missing information with seven colleagues watching.
The rule is easy. Enforcing it is where it gets culturally uncomfortable. When a ticket fails the bar mid-meeting, the correct move is to pull it out of the sprint and turn it into a spike — and pulling a ticket out feels, in a Japanese meeting, like telling the product owner their work wasn't good enough. So the room's instinct is to keep going, 持ち帰り (mochikaeri) the open question, and plan the ticket anyway on the assumption it'll be fine. It's usually not fine. That specific reflex — being reluctant to visibly reject somebody's item in front of everyone — is worth a lot of hours per year, and naming it out loud as a team helped more than the rule itself did.
3. Stop buying accuracy with meeting hours
The third one took me longest to accept, because it means giving up on something that feels like the point.
We were trying to produce a plan that would be correct. That's what the extra three hours were for: the third round of debate on a number, the fourth pass over the same ticket. And the accuracy you buy in hour seven is worth almost nothing — by then people are tired, and a tired room converges on whatever number ends the meeting. Our estimates only ever drift upward in that phase, never toward being more right.
Some of this is a language problem, which I don't think is a coincidence. Nearly every agile term on our team is English in katakana — スプリント, ベロシティ, ストーリーポイント — but the one that stayed Japanese is 見積もり (mitsumori). It's the same word for the formal quote a vendor sends a client before signing a contract. Everyone knows a story point isn't that. Some part of the brain still hears a figure you'll be held to, and behaves accordingly.
So we've started trying to be less right on day one and to move the variance somewhere cheaper. Plan to roughly 70–80% of capacity instead of filling it. Put thirty minutes mid-sprint on the calendar to re-plan against what we've actually learned by then. That's not a hack, incidentally — the Scrum Guide explicitly expects it: if the work turns out to be different than expected, the developers "collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal."
The gap between plan and actual doesn't disappear. You just choose where you absorb it, and absorbing it in a thirty-minute mid-sprint check costs less than absorbing it in three extra hours of planning that were mostly guesswork anyway.
Where we actually are
Still about eight hours. I'd like to end this with the version where it's three, but I'd be making it up.
Refinement is the one that visibly moves the needle: the sprints where we actually held the hour are the sprints where planning ran closest to its five. It's also the first thing we drop when the sprint is on fire — which is exactly the sprint whose planning will then run long, so a bad sprint quietly produces the next one. We're not disciplined about it, and I let it slide as much as anyone does.
The ready bar is the one I'd bet on longest-term and the one that's hardest to hold. It only works if somebody is willing to say "this isn't ready, we're not planning it" in front of the whole team, and I don't always want to be that person either.
What has changed is that the eight hours stopped feeling mysterious. We had built one meeting and quietly asked it to do three jobs — analysis, planning, and producing a number everyone would stand behind — and the exhaustion was that bill arriving once every two weeks. If your planning day also ends with everyone wrung out and a plan that doesn't survive the week, that's where I'd look first. Count how much of those hours is the first time anyone in the room has properly read the ticket. On our team it was most of them.
Sources
- Scrum Guide (2020), Ken Schwaber & Jeff Sutherland — Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint, and is usually shorter for shorter Sprints; Product Backlog refinement is "an ongoing activity"; developers "collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal." The guide defines a Definition of Done and contains no "definition of ready." https://scrumguides.org/scrum-guide.html
Top comments (0)