Wednesday, June 30, 2010

Up To Date

I've been in more than one series of events like this:
"We're starting to put down some dates for the Sweetums* release."
"Okay. What's in it?"
"Stories X, Y, and Z. We've put a brief writeup of each in Jira.**"
(pause while we go look at the stories and estimate the test effort on each as well as the estimates on how many bugs will come through, etc.)
"All right, we're probably looking at 4 weeks between feature freeze and code freeze, and 2 weeks after code freeze for final verification."

And then time passes. We start coding tests, looking at early builds, etc. Development, well, develops.

Inevitably, something changes. We might get a new customer who really wants a feature, or we might find a bug that needs to be fixed for the next release, or we decide to drop a story that seemed important but turned out not to really matter. Net net, something changes. So we have another conversation:

"What's the new estimate for this release?"
"Umm.... is everything updated in Jira?"
"Yeah, except we're not doing story Y, and we're doing story W."

At this point the conversation needs to stop. We have a process. We have a place that defines what's in a release. Let's use it.

If you've defined a place to keep information - the contents of a release, bugs and what's been done on them, employee phone numbers - then that place should be kept up to date. It seems like a lot of work sometimes, to keep updating the information location. It's worth it, though. It saves a lot of other people time, and it works to train them to trust the information location. If it's up to date always, then people will come to trust it. You'll spend less time explaining status and more time working.

And less time on status and more time working sounds great to me.

* We name our releases after muppets where I work. This is Sweetums:

** We keep our stories in Jira so we can track them and do things like attach bugs to stories, etc.

No comments:

Post a Comment