Why we use tickets in a distributed team
I had a discussion with a client, and strangely found myself arguing in favour of tickets. Maybe it is just because I am contrarian :-).
I dislike debating about hundreds of open tickets more than most people. I tend to recommend using fewer tools. If we were sitting in the same office, I would stick some post-its on the wall.
Why do we stick virtual stickies on a virtual wall?
- So we can see what is up next, when we want. When we’re developing software we need to focus on one thing, to make it simple and solid. Having the cards on the wall as a reminder allows us to forget what to do next, and focus on what to do now.
- The wall has limited space, and we can lay it out however we want, to visualize what is important to us now. Are there too many items waiting to be checked by someone else? Let’s make space for that. Are there many things we have made, but not shipped? Let’s make space for that.
In the spirit of tools, I’m not going to recommend any. For this purpose, the fewer features it has, the better.
Let me recommend some anti-features instead:
- You really don’t want to be able to search through tickets, this makes it easier to keep more of them
- You don’t want to attach files, this makes it easier to replace conversations between developers and others with elaborate requirements specfications.
- You don’t want to be able to add custom fields to a ticket. Maybe some colors help, but that’s it. Before you know it, someone makes managing the ticketing system a full-time position.
- Graphs and metrics are cute, but also may indicate you have too many tickets, and care of them too much. I find cumulative flow diagrams useful if there are already too many tickets, to track progress towards having fewer. Go outside, observe a user instead.
So we are on the same page, I don’t want tickets either. Having a few of them on a virtual board just makes it easier for all of us to track what we’re doing now, and what we’re working on next.comments powered by Disqus