FizzBuzz is a simple kids game, often used as a test at programming interviews. It goes like this:
It takes 3-5 sprints for a team to establish stable velocity. And then we're supposed to use this velocity to forecast future effort, i.e. amount of effort we can put into future sprints. Now, this works fine if nothing changes. For velocity to work, it is assumed that the same people will be working on the same kind of problems, using the same technology, with the same productivity and motivation every day for the duration of the project!
If you're one of the lucky few where nothing ever changes in your team and your project then congratulations, velocity as a forecasting tool will work well for you! If, however, you're one of the unlucky 99.999% where life gets in the way and causes pesky changes in your team or project then tough luck! Each and every time a team member falls ill or simply becomes unhappy, or you have to use a different tool, or the sprint duration changes or simply a previous assumption about your project is invalidated then Bang! Velocity blows up in your face. Welcome to another few sprints until you establish stable velocity again - enjoy it while it lasts because in a few more sprints it's going to blow up again.
Velocity is a placebo. Is one of those things that gives us the illusion that we're in control of something and makes us feel better for it, while it has very little practical effect.
The way to deal with change in not to assume that it won't happen and -when it does- start all over again. The way to deal with change is to be prepared and -when it comes- make sure we can assess it, measure it and manage it. We need a method that breaks down change, weighs its effects and allows us to quantify it and adjust to it.
Yesterday I attended a talk about truth tables. It was based on the premise of an interview question and whether the candidates were able to model and represent in code the appropriate truth table. The problem question was this: