Velocity Inflation Triggers Productivity Recession 6
A team’s velocity is a measure of its productivity. A higher velocity means more work is being completed each iteration and a team that shows an increasing velocity from iteration to iteration is being more and more productive. This isn’t necessarily a good thing.
In Extreme Programming (XP), a team’s velocity is defined as the number of story points completed in an iteration. We can track the velocity for each iteration and calculate the average velocity over several iterations. If we know how many story points comprise an application, we can even project when an application can be released . Velocity is a very useful measure of a team’s capabilities. I have found it to be a much more reliable (make that infinitely more reliable) number to be used for project planning than asking developers for time estimates based on requirements.
Because velocity correlates to a team’s productivity, there is a tendency for managers to try to “goose†the velocity. The technical term for this is a stretch goal. Just like the coach of a sport’s team trying to get the team to play better, I can imagine project managers saying at a team meeting at an iteration boundary, “Come on team – you did 22 points last week, what do you say we try for 25 this week?†This same manager probably buys those motivation posters of eagles soaring and hangs them all around the team room.
The programming team takes pride in their achievements and they also like to see their velocity increasing. They will try to persuade the Customer to give them points for any bit of work they do. I can imagine a developer putting in a few minutes work to change the position of a GUI button on a screen and begging the Customer, “Can I get a point for that?â€
XP teams can become obsessed with their velocity, but increasing velocity isn’t always a good thing. A team can inadvertently become so focused on getting points done that they sometimes forget the real goal – to deliver a quality product.
This became apparent to me recently when I visited a client to see how they were doing in their transition to XP. Their velocity had skyrocketed since I last saw them – and it was definitely not a good thing.
When Object Mentor does an XP transition with a client, we start with our XP Immersion course to get everybody on the same page about what our goals are. Ideally, we use two instructors, one to train the programmers in topics such as Test Driven Development and Refactoring, and the other coach teaches story writing, iteration planning, and release planning to the customer team. We then bring the two groups together for a day and have the customer team drive the programming team on a classroom exercise so everybody can experience how the process works. The instructors then stay and work with the team for a few iterations, coaching them on how to use what they learned in class on their own project.
Such was the case with the client I mentioned earlier. I was working with the programmers and the other coach had the customer team. When it came time to estimate stories, the other coach suggested using an open-ended scale. Where I like to use a scale of 1-5, this team was using a 1-infinity scale. That’s fine, it doesn’t really matter which scale you use, as long as whatever scale you choose is consistent. Stories were estimated according to their relative complexities, iterations were planned, and the programmers started cranking out code. After a few iterations the team’s velocity settled to a value of about 14 points. The team was doing fine and it was time for me to move on and let them do it alone.
When I returned to do a process checkup, their velocity had climbed to 48 points. Wow. This new process must really be resonating with the team. I purposely timed my visit to occur on an iteration boundary and we conducted a retrospection on how well the team was adhering the the XP practices. This turned out to be the bad news.
With a focus on getting more points done, it seemed that the team had abandoned many of the practices. Programmers weren’t pairing, weren’t writing unit tests, and weren’t refactoring their code. Customers were trying to stay ahead of the programmer’s ever increasing productivity abandoned writing automated acceptance tests in FitNesse and were now back to manual testing. I was heartbroken.
Beck teaches that one of the things teams have to do is to adapt the practices to the organization. Perhaps what they were doing was adapting. Adapting to the point that they weren’t even close to doing XP anymore, but adapting nonetheless. I wondered how that was working for them.
I observed the iteration planning meeting for the upcoming iteration and I noticed that all of the user stories were bug fixes from the previous iteration. No new functionality was being added to the application, the team was essentially spinning its wheels. So even though the velocity indicated a very productive team, the actual productivity was essentially zero. There must be a lesson here.
Velocity is what it is. You must take great care when encouraging a team to increase its velocity because you will always get whatever you’re trying to maximize. You have to be careful that you are maximizing the right thing. Want to maximize number of lines of code produced? Well you’re most likely going to get a lot of really crappy code. Want to maximize the number of unit tests that developers write? You’ll get a lot of them, but they’ll probably be worthless. Applying pressure to increase the velocity might make developers to subconsciously inflate their estimates or worse, abandon good development practices in order to get the numbers up.
Great article, Bob. As a developer, I certainly know the temptation of not adhering to best practices in order to get a few extra points. Or the ego in the back of my head that wants to ‘beat’ last iteration’s score.
In reality, a consistent velocity is better for the company/management as they can better schedule projects.
In a stable group, if the velocity is changing, you are probably doing something wrong. Either estimating differently, doing stories that are too complex or not defined enough or changing your development practices.
In theory, the only time your velocity should be changing (that I can think of) is if your staffing is increasing/decreasing.
Thanks again Bob. Nice article.
I think the phenomenon you’re describing is commonly known in the US as “Playing to the measurement”.
How about an increase in team’s knowledge and skills?
That’s probably true, Chris. But I’ve found that in my groups an increase in knowledge and skills are often offset by more aggressive estimates.
A “build a web service” story might get a much lower story point estimate than it did a year ago now that the team has built many web services since that time.
Of course, you could argue that our estimates shouldn’t be changing like that, but that is the reality of how my team ends up estimating. I suppose that is a whole different debate.
Interesting article.
However, I have a feeling that abandoning practices like pairing, refactoring, unit testing may not be result of ‘playing to the measurement’. Perhaps the client staff just didn’t get it and pairing, unit testing wasn’t considered as useful… If they found it useful they would certainly used it to get more work/better quality work done.
On the other hand getting story points for bugs is clearly a sign of reckless chase for bigger and bigger velocity figure.
Nice article, Bob—I love to hear about failures because we can learn much from them. I’m surprised that they were using bug fixes as stories: was this intentional, i.e., they didn’t see these as bugs but just new features? I always treated bugs (i.e., didn’t meet the original story card requirements) as part of the original story’s velocity.
It also makes me wonder how they accepted the stories as being done? Were they done when the code was checked in to the source code control system? When all the tests pass? When QA did some manual testing? When QA’s automated tests passed? When the customer’s acceptance tests passed?
It seems to me that taking credit for stories completed before anyone’s actually tried the feature is just asking for code to be stuffed in to the product and unless the team is really on top of things, is a disaster waiting to happen.