Do you know what your team's sustainable pace is? Do you believe it is equal to their Velocity?
Let's try to answer that question.
Scrum tells us that we should be Sprinting toward the goal of delivering working software. But then it tells us that we should work at a pace that is sustainable over the long haul. Is that an oxymoron? Or is that Zen?
Velocity is the rate at which the team is delivering valuable-working-tested software to the customer. If that velocity is at a steady state then it is the sustainable pace for that team - right? I'll agree to that - if that velocity is relatively steady state over 2 years of time. Then there is a high likely hood that the velocity accounts for vacation, holiday, sickness, team member changes, and growth of the scope of the definition of done for a sprint.
So how do you get a team working on a project to a steady state for two years? In this industry - you don't! But that doesn't mean we can approximate the point where steady state sustainable pace would be in the future. Issac Newton invented calculus just to predict the complex motion of the earth around the sun. Surely we could borrow his limit equations to project the function of sustainable pace and predict where that pace would be in a future state. That is after all not much different than what he was trying to do - predict the future. Where would the earth be at some point in the future, in relation to the sun.
Assume that a team can Sprint at a Velocity average of 34 pts within the first 6 months of their project. They have gone from the starting gate to Sprinting. They start to reliably deliver working tested software every few sprints - they are in the groove. This is not their sustainable pace. Their sustainable pace is 1/3 that value.
Wow! One-third, that's a bold statement.
What do you think?