How many story points per sprint?
Yours, measured. Anyone else's number is irrelevant — and the moment someone outside the team starts caring, the system breaks.
Velocity is yours, measured. The right number is the one your team has actually delivered.
Searching "how many story points per sprint" is a category error. There is no industry number; there is no "good" number; there's no per-developer-per-day rate. Velocity is the team's measured throughput, and the only useful version is the rolling average over the team's last few sprints. Fifteen points, forty points, a hundred points — none of those are right or wrong. They're calibrated to the team's reference story.
The follow-up question — "but is our velocity good?" — is the actual trap. The moment velocity becomes a productivity metric, points inflate. Within two sprints, every estimate is 30% bigger than it was, the velocity number "improves," and nothing is actually shipping faster. This isn't a hypothetical; it's the most common failure mode of the technique.
What you can do with velocity
- Project a date for a known scope: scope ÷ velocity = sprint count.
- Decide what fits in the next sprint: pick stories until they sum to ~80-90% of recent velocity.
- Spot when something has changed: a 30% drop is signal, worth a retro conversation.
What you can't do with velocity
- Compare it to another team's velocity. They have a different reference story.
- Use it to grade the team. Points start inflating the moment that happens.
- Convert it to "expected hours per developer per day." That's hours estimation with extra steps.
If a manager outside the team is asking "is your velocity good", the answer to fix is upstream — not the velocity number.
See story points vs hours for why the conversion is the failure mode; velocity as a productivity metric for the organizational anti-pattern.