Velocity and capacity are not as interchangeable as pens and pencils. Velocity is the amount of work that a team can complete in a sprint that pertains directly to new product development. Capacity is the total amount of work that a team can complete in a sprint altogether. In a post at her blog, Natalie Warnert discusses the importance of distinguishing this difference.
Fit to Burst
Between technical debt, administrative tasks, and other odd jobs, teams are almost never working exclusively on backlog items during a sprint. That means a team might have a velocity of 20, but when their non-product work is factored in, a hypothetical extra 7 points might be added. It is important to acknowledge this gap and for product owners not to assign additional work that impedes into this “phantom” space, because it will result in an overworked team that likely does not fulfill all of its obligations.
Warnert adds this:
… even if my team’s velocity is right at 20 points and that’s what the PO forecasts for the sprints in the release, that’s not leaving the team any buffer time for new features that take more to develop, design, and test that estimated (remember, when we estimate we’re often wrong but it’s a good practice for most teams) or other work that can pop in. I’m not going to get into estimating defects and tech debt here… but the point is that we too often over-commit… and under-deliver because we do not think about risk and complexity enough in our plans. And our plans suck – it’s not the plan we need but the act and conversation of planning.
For some additional illustrations that drive home the point, you can view the original post here: http://nataliewarnert.com/capacity-versus-velocity/