I recently wrote about writing tasks for tomorrow so I have clarity. That has been really good, but I quickly ran into organizational problems. I was storing them in a Wiki and that just doesn’t scale.
For tracking work on TDP, I’ve been using JIRA. JIRA gets a pretty bad rap and I don’t really understand why. Sure, it isn’t free and the pricing scales up a bit strangely but it’s easy. JIRA OnDemand works very well and it’s worth $10 a month (until we get to the 11th account!)
However, JIRA doesn’t have any organization support for this concept of ticket stacks. It’s a short-coming that can be addressed through a few different ways. I most likely will end up writing a script to gather and organize these, but for now I came up with a simpler way.
While I’m writing about doing this in JIRA, it isn’t JIRA specific. Anything here could be adapted into any reasonable ticketing system. A reasonable ticketing system is one with custom fields and search.
The Timeline
Each ticket now has a custom field called Timeline. This field keeps me sane, and it has the following options:
- Vapor (actually “None”, the default option)
- Backlog
- Active
- Done
Vapor
Vapor is something that is an idea, observation or some other ticket that I can’t work on. Something I’d like to do but I have no idea when I’ll be able to get around to it. In scrum terms, it equivalent to the product backlog.
In this scenario, it’s a backlog that I’m not ready to really think about. Once I am, I put assign the Backlog label to it.
The Backlog
The backlog contains tasks I’m mentally aware of but don’t know quite when I’ll work on them. I’m actively hoping to get them done in the foreseeable future. I will tell people about them. I try to limit this to things that will definitely be done in the next two weeks.
The in the scrum world, they have a defined sprint backlog. I don’t. Mine is a conveyer belt. I guess you could say that I simply have one day sprints.
Active
The tasks I setup at night that I will be working on tomorrow are in my Active stack. This also includes new work that will take more than one day. The task simply stays in “Active” until it is done. Once I start working on something, I try very hard to not move it out. I may in the future require a “stalled” status.
It’s very simple to think this way. At the end of the day I look at the tickets listed “Active”. That’s my tomorrow.
Anything in the Active queue should be actively worked on. It’s very simple.
Done
As I complete tickets, I mark them as Done. This moves them out of my Active worklog. Anything that is marked as Done I can then worry about deployment and continuing in the normal ticket workflow (such as resolving it and passing it off to QA).
Tickets for everything!
Now, this means I’m creating a lot of tickets. Some of which have no product relation or are simply tasks that would be better suited as a single line item in a Wiki. However, why bother?
This system works very well and I have project space for it. There is no limit to how many tickets and tickets have a built in history for managing everything I could possibly want.
I can add comments and talk to myself all day, and it’s very useful.
A little organization goes a long way
This organizational step has really helped me in the last few days. I hope to keep it up, and with TDP goals to keep me honest, it’s really not hard.
I’ll definitely want to automate some of it to make it easier, but that part will come soon.
Very Scrum Like
I like the Scrum methodology) a lot. In the past when I’ve used it I’ve found it to be very natural. When I thought how I wanted to model my workflow right now I looked to it for inspiration.
If I were working with more people I would formalize on Scrum and utilize that. For now, I have a very simple way of doing Scrum-like work in a way that matches and doesn’t introduce friction.