How Many Story Points Per Sprint Is Normal?
Quick answer
There is no universal "normal" for story points per sprint. A team of 5 developers might complete 30 to 50 points per 2-week sprint, but this number is meaningless outside of that specific team. Story points are a relative measure, not an absolute one. The only useful comparison is your own team's velocity over time.
This is one of the most searched questions in agile, and the honest answer is: it depends entirely on your team. There is no industry benchmark, no target number, and no "good" velocity. But that does not mean velocity is useless. It is one of the most practical tools for sprint planning when you use it correctly and one of the most harmful when you use it as a performance metric.
Why is there no standard number?
Story points measure relative complexity within a single team. A "5-point story" means something completely different on Team A than on Team B. Team A might calibrate their 5 as "a full-stack feature with tests," while Team B calibrates their 5 as "a simple API endpoint." Both are correct. The number only has meaning within the team that defined it. This is why comparing velocity between teams is not just unhelpful but actively harmful. It incentivizes teams to inflate their estimates to "look faster," which corrupts the entire estimation system.
What does typical velocity look like?
If you survey agile teams, you will find velocities ranging from 15 to 80+ points per sprint. A small team of 3 developers might sustain 20 to 30 points. A larger team of 7 might hit 50 to 70. But these numbers tell you nothing about productivity. A team completing 20 points of high-quality, well-tested features is delivering more value than a team burning through 60 points of half-baked stories that come back as bugs next sprint.
How do you find your own baseline?
Track your completed points for 3 to 4 sprints. Ignore the first sprint if the team is new to estimation. Take the average of the remaining sprints. That is your baseline velocity. Use it for sprint capacity planning: if your average is 32 points, plan for 29 to 35 points next sprint (roughly plus or minus 10%). Do not plan for exactly 32 because velocity naturally fluctuates due to holidays, sick days, meetings, and the occasional gnarly ticket.
What if velocity is going down?
A declining velocity is not automatically bad. Common healthy reasons include: the team is doing more code reviews, adding test coverage, paying down tech debt, or onboarding a new team member. Common unhealthy reasons include: scope creep within stories, too many meetings, unclear requirements, or burnout. Look at the trend alongside team morale and code quality before reacting.
Should managers see velocity numbers?
Velocity should be visible to the team and the scrum master. Whether managers see it depends on organizational maturity. In healthy organizations, velocity is a planning tool, not a performance metric. In organizations that use velocity to evaluate team productivity, teams will learn to game the number by inflating estimates, which makes velocity useless for planning. If your organization is not ready to use velocity without turning it into a target, keep it within the team.
Track your team's velocity over time
Free sprint velocity calculator — no signup required.
Try Velocity Calculator