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.
Common questions
How many story points per sprint is normal?
There's no industry number. Velocity is your team's measured throughput — the rolling average of points completed over the last few sprints. Fifteen, forty, a hundred: none are right or wrong, because each is calibrated to a different reference story.
How many story points per sprint per developer?
Don't compute one. A per-developer rate turns story points back into disguised hours and invites the cross-person comparison the technique is designed to avoid. Velocity is a team number, not a sum of individual quotas.
How many story points are in a two-week sprint?
However many your team has historically completed in a two-week sprint — measure it, don't target it. Pick stories until they sum to roughly 80–90% of your recent average, and leave room for the unplanned.
What is a good velocity for a scrum team?
A stable one. 'Is our velocity good?' is the question that breaks the system — the moment velocity is graded, points inflate and nothing actually ships faster. A good velocity is one you can plan against, not a number that keeps climbing.
See story points vs hours for why the conversion is the failure mode; velocity as a productivity metric for the organizational anti-pattern.