How much can the team commit to this sprint?

Questions CTOs ask

How do you calculate sprint capacity?

Sprint capacity is calculated by multiplying available developer-days by a focus factor. Start with total working days in the sprint, subtract planned time off (vacation, holidays, training), subtract meeting overhead (typically 20-30% of time for ceremonies, 1:1s, and ad-hoc meetings), and subtract meeting time and a support-overhead percentage, which is what this tool asks for. For example, a team of 5 developers in a 2-week sprint with 1 day off and 25% meeting overhead has: 5 x 9 x 0.75 x 0.7 = approximately 23.6 productive developer-days.

What is a good sprint velocity and how do you improve it?

There is no universally "good" velocity — it depends on story point calibration, team size, and domain complexity. What matters is velocity stability: a team should have less than 20% variance between sprints. To improve velocity, focus on reducing work-in-progress (limit WIP to 1-2 items per developer), reducing context switching, improving estimation accuracy through regular retrospectives, investing in developer tooling that removes friction, and protecting the team from mid-sprint scope changes. Sustained focus on WIP limits and estimation accuracy usually shows up as steadier velocity before it shows up as higher velocity.