Agile Otter Blog

(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: Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying. 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. Though velocity is a gauge, it is subject to  Goodhart's Law . It is rather dodgy when used as a basis for governance. 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 rec...

So here is a failure mode I finally had time to think about. I saw a version of this play out, but here's the basic idea: The Customer doesn't get as many stories as he'd like, so he pads the story with functionality that has a lot of leverage. Then when it's done, he can use it many different ways. This makes it a little hard to see the original user request in the fluff, but it does accomplish its original task (too). The story is too large, but it is pushed to development, and developers take it on by sending a few guys offline to work on it for weeks/months. In the meantime, a developer realizes that this feature is considered critical, so it has to be pushed. He has other features he would like to ship, but they're not related to this one. On the other hand, if he can sneak in some of his feature into this story, he is assured it will be released. This makes the story later, so there's more overtime, and it takes on more testing risk, but it's a g...