Velocity is a simple concept to grasp when planning and managing an agile project. It is one of the first formula you learn in maths (or is it physics), speed equals distance over time. On a project the distance is scope, measured in the number of ‘points’ you need to complete. So if the team has a hundred points worth of scope and a velocity of ten, they will complete distance (scope) in ten weeks. It’s a simple calculation, but is dangerous and wrong. It fails to take into account acceleration.
Just in the same way that it takes a car time to accelerate to a meaningful speed, so a project takes time to reach it’s planned velocity. To reach 60 miles an hour takes ten seconds and means moving through the gears. You don’t put your foot on the accelerator and suddenly find yourself doing sixty. Nor do you put the car into forth gear and expect to move without stalling. It is the same in agile projects. Velocity is misunderstood; you cannot expect to have your planned velocity immediately without acceleration. Similarly, putting a fall sized team onto a project is like trying to start in forth gear. You will stall.
When planning an agile project you need to consider acceleration. The first iterations will be slow as you come up to speed. Secondly you need to be in the right gear for where you are at. Start in first (small team) and change gear (ramp the team up) as the velocity requires it. Better to have the engine screaming in first (change gear) than to have it stall before it’s even got going.
Sadly, this means the simple pictures on burn-up and burn-down charts are wrong. They need to take into consideration acceleration and appropriate gearing. And that is advanced maths.