3x full-time engineers = 240 hours of work (40h x 3ppl x 2-week sprint).
Because Velocity must account for for meetings, interruptions, onboarding, rework, waiting, handoffs, uncertainty, productivity fluctuations, pair programming, it's impossible to calculate it in advance by just counting heads.
✅ Velocity is determined empirically, by running a number of sprints, and then seeing how much the team can actually accomplish. Comfortably, without cutting corners, on Wednesday or Thursday. Not on Friday 6pm.
💥 Velocity determined by counting individual hours is a recipe for disaster. Empiritally determined team's velocity will always be less than total work hours. And because velocity is less than sum of individual work hours, that leads to conflict, pressure, and micro-management.
I've seen situations like this:
Your velocity is two times less than work hours. Maybe we should pay you half as much? :)
I've also seen teams increasing velocity thanks to collaboration, pair programming, and mentoring (say, from 120h to 160h). But the managers who kept seeing velocity through the lens of individual hours asked them stop doing that to reach 240h :-) This is all because...
Sum of individual hours is not correct metric for velocity. The better measure of velocity is story points.
A story point if an abstract measure of effort, that take into account volume, complexity, and uncertainty of a problem. How many story points the team can comfortably deliver per sprint? That's a good question to ask. 30 story points can be an answer. So we pick 30 story points of work into our sprint. Nobody is focusing on or talking about hours.
Velocity combined with story points creates a simple and healthy contract between the engineering team and the customer. It focuses on how much work the team can comfortably deliver without burning out rather than a sum of individual hours. It lets the team decide how to work (without convincing anyone) and how much work to take to maintain a sustainable pace. The customer and manager only decides on priorities. In other words – the team decides how much and how; the customer decides what.
There are other benefits of using story points instead of hours. For example, story points let people with differnet skills and productivity quickly agree on estimate. With story points, we don't have to agree on how much something is gonna take and to whom. We need to agree on volume, complexity, and uncertaincy. Fast runner or slow runner, 1km is still 1km.
You can learn more about story points in Agile Estimating and Planning book.