I’m still a little bit nervous about making a team feel bad if they come under. After all they may do everything right and still have a flailing velocity for awhile. I would hate for them to get discouraged or resort to bad practices to make their agile adoption a “success”.

But now I understand the situation you’re trying to avoid. At the beginning of a project our estimate would change every single iteration (I used standard deviation but certainly last-time’s works too). However, once we got into our groove and got a steady velocity going, we would get to use the same value and hit it every time.

So you’re totally right to point out how we need to be adapting our planned velocity as needed.

The point of my blog post was not to point out the failure, but rather to say don’t get in the habit of moving work to the next iteration as though it wasn’t a failure. I think we can both agree that a team moving work from one iteration to the next on a regular basis is an unhealthy situation. I don’t want teams to think they are “close enough” so it is ok. That’s really what irks me. I’d rather have the team admit there was an issue (whether they call it a failure or not, they did not meet the commitment they made at the start of the iteration), and go about fixing it than have them say it was almost good enough so don’t worry about it.

In your example, if the team had an expected velocity of 100 and only delivered 95 (whether their fault or not), I want them to commit to only 95 next iteration (yesterday’s weather) and get it completed, or even pull more from the backlog. I don’t think it is healthy for them to say “good enough” put these 5 points in the next iteration and then add 95 new ones and again miss by 5 points. It becomes habit forming and that is a bad habit or antipattern. Unfortunately, too often I see the 2nd way of solving the problem (5 from last iteration and 95 new) instead of the 1st way (5 from last iteration and 90 new for a total of 95).

I hope that makes more sense and gives you the context of what I was trying to write.

Oh, and I agree 100% with your final paragraph. Well put!

To me, failing an iteration is not completing it. I know you recently posted about it and I agree that a team should never ever quit an iteration. Ever. The only reason to do that is to make yourselves look better than you are and that’s called ego, not agile.

I think in this case you are using the phrase “fail an iteration” to describe a team that plans to do 100 story points and then at the end of the iteration has only completed 80 story points. If so, I totally disagree with the qualification of failure and more than that, I think it’s a harmful mindset (regardless of the exact wording).

To call it a failure implies that they screwed up (even if they did everything right). No one likesto be a screw up, so this leads to shirking on other stuff. Important stuff that you can get away with not doing, like adequate testing and fixing TODOs in the code and refactoring ugly design. And people start padding their user stories and underestimating their iteration velocity and thens screwing around in the last couple days so it’s not obvious they did that, and yuck!

Instead, what’s really important and valuable is having a steady velocity (as you mentioned). However, we should not unnaturally force a steady velocity by insisting that one velocity is success and another is failure. If they continue to focus on quality and good story estimates and general good practices, a steady velocity will follow organically. Then it will become easier and easier to predict how many story points we can do in the next iteration, or the next 5 iterations, etc. A steady velocity (and all the benefits it provides) is a result of successfully implementing agile, not a requirement to begin using agile.