Velocity – what will we be able to deliver this week?

The final building block of our introduction to agile is velocity. In addition to employing user stories to break down big features into manageable junks, maintaining a backlog for ruthless prioritizing, and story point estimates, velocity will help you find out what you can deliver in a week.

Looking at “Yesterday’s Weather” to Learn About Your Velocity

To estimate what you can achieve within one week just add up the story points of all the really finished stories from the previous week. That number is your velocity and is also a pretty good estimate of what you should be able to deliver in the upcoming week. To figure this out, just take story by story from the top of the prioritized backlog summing up the story points until you reach the velocity from the previous week. Mike Cohn is able to explain this much better in Agile Estimating & Planning.

Delivering Nothing for Weeks – The Transition is Hard

To be honest, we were not able to do all this in the first weeks of our transition. In the first week, not a single story was really completely done so our velocity was zero. For the second week we took fewer stories, but we still weren’t able to finish any – not even the ones from the previous week! Again, velocity zero. In the third week we were finally able to close two or three stories from the very first week, but it took us a couple more weeks to begin regularly delivering a stable amount of story points.

Unstable Code And Unfinished Work Kill Productivity

From an external viewpoint development came to a grinding halt. For nearly a month we didn’t deliver anything! Let’s take a closer look: Before our transition we “delivered” a couple of features every week. By “delivered” I mean we released some code to production. But usually this code wasn’t even close to being stable or complete. So the developers kept adding missing pieces to already released features while they were supposed to work on new ones. Additionally, a lot of bugs (often quite critical) were discovered during the first days of running new features in production. Critical bugs caused a lot of “stop, drop and roll” fire-fighting leading to some urgent bug fix releases. Such “super urgent” bug fixes hardly got any testing and therefore led to even more bugs.

“Done” means: “I don’t have to think about it anymore”

So, while it looked like a feature was done weeks before, in reality, the developers were still working on it and its aftermath. Only by “stopping the line” and being ready to cut down the velocity to zero, was I able to make everyone aware of these facts. I was also able to insist that developers work on a story until it was complete, stable and released. For me, the definition of “Done” is: “I do not have to think about it anymore”. As long as a story is occupying any portion of my or anyone else’s brain it’s not done!

Making Flaws in the Process Visible is the Starting Point For Fixing Them

Introducing velocity to help measure your progress makes a lot of flaws visible which, in turn, finally gives you the chance to fix them. Eventually, by addressing all these flaws you’ll dramatically increase your delivery rate with a much lower bug count.