How do you know you're in Ticket Hell? You don't come in one day and think, "Gosh, who's microwaving brimstone at this hour?" It's a slow, subtle thing that builds up over several releases.
It starts with one release, when you realize that you have slightly too many tickets for your six week run. No problem! Just bump those two to the next release. They were just minor widgets anyway.
The next release, which had just the right number of tickets, is now heavy by two. That's not too bad, though, so you just keep going ahead. At the end of the release, you realize you didn't quite finish up those two tickets, and oh, these other two didn't quite get to the finish line either.
So you bump them.
After a while, you end up with a release filled with nothing but bumped tickets. No one remembered why they wanted to do any of them. They've all been half-worked on. They've been bumped around from developer to developer. There's no big, cool things to work on: just a bunch of bike-shedding and feature creepers.
Welcome to six weeks of Ticket Hell.
How did we get here?
It's very tempting to bump tickets without thinking about why they're being bumped. I've noticed a few themes to bumped tickets:
- The requirements weren't clear: sure, they may seem clear, but when a developer tries to implement them, there are dozens of ambiguities and subtleties that lead to the ticket circling the drain, but never going down
- There's a technological blocker. It looks like it should be easy, but there's some stupid little thing, like the date not rendering correctly, that's keeping the ticket from closing
- It's really unimportant. No one is going to scream or cry if this ticket isn't finished
- It's really, really boring to do
Ticket Hell is actually quite easy to get out of, if you shore up your emotional attachment to finished tickets, and accept that sometimes, it's best just to close them off with a 'wontfix.'
Manage how many tickets you have in a release
Figure out how many tickets you can fit in a release, and stick to it. More tickets leads to more places for tickets that should just die can hide. How many tickets can your ticket poker deal with in a day? How many can a developer seem to keep in his brain pan at once? Your lowest common denominator should be the person on the team that has to touch every ticket, and can't NOT look at a ticket. Make that number something that he/she can deal with.
Know how long your tickets will take
We estimate hours for each release by attaching hours to tickets. Every person has to go through every ticket and estimate his/her time needed on each ticket. One amusing side-effect of this procedure is the ability to see what new feature the developers and designers are going to want to dog-pile on. We once had a ticket for making a blog that, literally, had every dev and designer throwing hours in for.
Once you have your hours in, do some math. The guys are working 40 hours a week for six weeks... but they have meetings and such. Reduce that to, say, 30 a week. They always underestimate, so up their estimates by, say, 30%. Which of those numbers is bigger? If it's the estimates, you have a problem, and need to start lopping tickets.
If you don't want to do it now, you're not going to want to do it later
So, your hours were right, your ticket number was spot on, but you still have a ticket left over. Do you bump it? Well, if it didn't get done, but no one is screaming about it, kill it. Who's there to care? And who is going to care next release? What are you going to do, outsource someone who gives a flying rat?
If you really want to do it, you'll make another ticket
But wait! Maybe we should just put the ticket in limbo! Someday we'll have time for it!
If you really want it done, you'll make a new ticket. Really. Maybe you'll even have a person who cares this time.
Tweaks take time, too
"But it just needs to do this one last thing..." Don't bump the ticket. Close it, and make a new one, this time just for a tweak. Why?
Well, for starters, the tweak should be clearly stated. Obviously, the original ticket wasn't getting it done. Secondly, you don't want the new developer digging through all the old crap on the last ticket to figure out what the tweak is.
Also, this forces you to add a ticket with its own hours to a release, adding it into your metrics.
Low priority = death
Every release has a few tickets that are 'low' priority. This is fine when you start... but as the release wanes, if they stay in 'low,' they become more and more likely to get ignored, then bumped. Want it done? Half-way through, re-prioritize and up their urgency.
And if something really is 'low' priority... do you really need it? Are you out of cool ideas already?
A warning
Some people hate it when you close tickets that haven't been completed. We had tickets that hung around for over a year because it was assumed that someday, we'd have the time. That the history on the ticket was vital to the health of the application. That someone would appear, screaming their head off, that the ticket that had been pushed for eighteen months was closed.
Sure, those things may happen. But that Ticket Hell, full of crap no one wants, no one wants to do, no one knows how knows how to implement?
That will happen.
1 comment:
All of the above is true!
Post a Comment