Agile Velocity Planning Calculator
Estimate how many story points a Scrum team can complete in a sprint based on team size, sprint length, daily hours, experience level, and story point sizing. Use it during release planning to forecast sprint capacity before historical velocity data exists.
About this calculator
Agile velocity is a measure of how much work a team can complete in a single sprint, expressed in story points. This calculator derives a theoretical velocity using the formula: Velocity = (Team Size × (Sprint Length / 7) × 5 × Hours per Day × Velocity Factor) / Hours per Story Point. The expression (Sprint Length / 7) × 5 converts sprint length in calendar days to working days. Hours per Day represents focused development time. The Velocity Factor (e.g., 0.7 for a junior team, 1.0 for an experienced team) adjusts raw capacity for team maturity and efficiency. Dividing total effective hours by the Hours per Story Point converts capacity into story points, giving a sprint commitment target that teams can use before they have observed historical velocity.
How to use
Example: Team size = 5 people, sprint length = 14 days, 6 development hours per day, velocity factor = 0.8 (moderate experience), 4 hours per story point. Step 1: Working days = (14 / 7) × 5 = 10 days. Step 2: Total hours = 5 × 10 × 6 = 300 hours. Step 3: Apply velocity factor = 300 × 0.8 = 240 effective hours. Step 4: Convert to story points = 240 / 4 = 60 story points. The calculator returns 60 story points as the estimated sprint velocity.
Frequently asked questions
How does team experience level affect agile velocity estimates?
Team experience — captured as the velocity factor — accounts for the difference between a team's theoretical capacity and actual output. A brand-new team spends time on onboarding, tooling setup, and establishing working agreements, so a factor of 0.5–0.6 is realistic. A well-established team with stable membership and mature practices may achieve 0.9–1.0. Mid-level teams typically fall in the 0.7–0.8 range. This factor also implicitly captures overhead from code reviews, testing, and refinement sessions that reduce net development hours.
What is the relationship between hours per story point and team velocity?
Hours per story point is the calibration constant that translates time-based capacity into the abstract unit of story points. If your team agrees that a 1-point story takes roughly 2 hours and a 3-point story takes 6, then your hours-per-point ratio is approximately 2. A lower ratio means the team can complete more story points per hour, inflating velocity. This value should be anchored to historical data from completed stories — without it, the velocity estimate is only as good as the team's collective judgment about story sizing.
When should teams use a calculated velocity estimate versus measured historical velocity?
Calculated velocity estimates are most useful for brand-new teams, newly formed squads, or early release planning before any sprints have been completed. They provide a starting point for capacity planning when no empirical data exists. However, once a team has completed two or three sprints, measured historical velocity — the average story points completed per sprint — is far more reliable and should replace theoretical estimates. Calculated estimates carry assumptions about focus time and complexity that real-world execution quickly invalidates, making them a temporary planning tool rather than a long-term metric.