Wednesday, February 6, 2008

When the Doing is Faster

Today, I broke process. (EEP!)

Our software development process, which applies to QA just like everybody else, says that you get a new feature (or new test, in this case) by doing the following:

  • Create a story stub candidate describing why you want it, what it is, and a very preliminary idea of size
  • Take this to the XP Customer Team, who will either defer it, send it to someone for more details, or approve it and put it in your queue
  • Get a good estimate on the story and re-prioritize in your queue based on the actual estimate (rather than the SWAG you had earlier)
  • Patiently work on other things until the story hits the top of your queue
  • Implement the change
  • Get the change reviewed
  • Check it in
  • Have someone accept the story
It looks like a lot of steps, but for something really urgent this can all be done in a matter of hours.

Today I skipped a few steps. I did all the right things getting the story into the queue. But when it hit the top of my queue I took a look and realized that to estimate it would take me approximately 15 minutes. To actually do the work would take me approximately 30 minutes. So I skipped straight ahead to "implement the change".

Moral of the story? If it's faster to do than estimate, don't waste time just because your process says you should. Just do it.

No comments:

Post a Comment