14 Weird Observations About Agile Team Velocity

(note: I added a 15th, but was worried that changing the title would invalidate links, so you get a bonus observation at no extra cost)

I frequently have to address questions about velocity, so in the interest of time I present all the answers here in a short post:

1. Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying.
2. Velocity is (frustratingly) a lagging indicator. It primarily tells you about the fundamental process and technical work you did weeks, months, or years ago. You seldom get an immediate, true improvement.
3. Though velocity is a gauge, it is subject to Goodhart's Law. It is rather dodgy when used as a basis for governance.
4. Velocity value is highly derivative of many factors, chief among them being the work structure of the organization. The more governance and procedure (permission steps, queuing and wait states, official limitations,  risk of personal blame, reporting and recording, stockpiling of tasks for the sprint-end) the lower the velocity.
5. The amount of effort expended by the development team has a nearly trivial effect on velocity. A team can game it by working overtime, but that usually causes more problems than it solves. "Trying harder" doesn't scale and doesn't last. 
6. Velocity is like a helium balloon: it goes up because it isn't held down, and it only goes down when forced. This is partly because people like to complete tasks and build on achievements. Nobody willingly reduces their level of accomplishment (though any sane person will stop "trying harder" week after week).
7. Perhaps surprisingly, the more team members "do their own work" and multitask, the lower the velocity tends to go.  
8. Also perhaps surprisingly, most teams can complete four two-point stories faster than they can complete a single eight-point story, so the "area of the rectangle" (points x people) is not the same.
9. Although people often short quality to get things done sooner in the short term, velocity in all sprints is reduced if the quality of the code the team encounters is low. The code they encounter today is mostly the code they've written until now. Next months' could be better or worse depending on how they work today.
10. Skill and information have effect on the velocity of a team. As they learn and collaborate, the velocity comes up a bit -- but probably not nearly as much as movement toward an orderly and non-turbulent work flow.
11. When a team improves, either the velocity will go up and story points will remain roughly the same or the velocity will largely be the same and the points assigned to a story will reduce. However, quite often both will happen to some degree. This is one of the reasons you can't compare velocities across teams (there are may more reasons).
12. A poor PO can damage velocity, but a good one cannot improve it (other than to stop damaging it). The PO can improve value, but not velocity, because her job is establishing content and priority.
13. If you only count finished, planned work in your velocity then you can use last sprint's velocity to choose how much planned work you can do in the next sprint. Otherwise, it's largely useless. 
14. One additional use is that "sine-waving" velocity is an indicator of "hangover" -- the practice of carrying stories to the next sprint and claiming full value for them in the latter sprint. 
15. The biggest problems with velocity come from not understanding it, and treating it as a general indicator of productivity or busyness. The secret is to not take it too seriously, and improve your work system and organization instead of improving your velocity.

That's rather an unfocused ramble through the world of velocity, but perhaps you will find it useful.