So, some feedback from a colleague of mine (thanks DocOnDev!) got me thinking about whether or not establishing a velocity goal for your team is really a good thing. Seems like an honest enough goal for your team - you have a deadline and specific features to meet and you set an iterative velocity goal as such to meet said deadline and features to be delivered, being careful not to have the velocity goal exceed what your team can deliver.
But, in setting that velocity goal up for your team, are you really communicating to your team (even if you don't mean to) that ALL you care about is getting to that velocity goal? Perhaps your team is then taking short cuts or avoiding large refactoring efforts so that they can complete stories as quickly as possible, compromising quality?
Perhaps the answer to this question really lies within each member of the team you're working with. I know developers who would never compromise quality to meet a date, but then you have the opposite spectrum of developers who may hard code unit tests to always pass! DOH!
I guess the lesson here is to make sure that it's clear to your team that even though we have a velocity goal set, it's important to never compromise the quality of the code base or our own personal integrity to meet said velocity goal.
Perhaps it also depends on your specific project - maybe the most important thing for the organization you're working for IS the deadline and a velocity goal becomes an effective means of ensuring that the team meets that deadline.
What's your take on having velocity goals for your team? Is this a good or bad thing?
See comments to this posting for additional thoughts on this issue!
Tuesday, March 16, 2010
Are Velocity Goals Really a Good Thing?
Posted by Grant H. Joung at 9:34 PM 26 comments:
Subscribe to: Posts (Atom)