Large projects question

G

gooms9

0
Hey, I'm just starting off with GTD and had a question about large projects. I'm a software developer, and I'll be working on two or three projects at work at any given time. We track bugs and tasks in Jira. These can be anything from, "the homepage link doesn't work when logged in as an administrator" to, "Implement login page functionality". There could be around 20 or more of these tickets assigned to me at any given time for each project. As I kill these tickets, more are added to my list. It's kind of a bottomless pit of tickets until the current release goes live.

My question is, how would I track these projects in GTD fashion? Would I create a project and name it after the actual project name I'm working on, and then just copy each of these tickets from jira into my next actions list? Or would I simply add a next action stating "Kill all tickets in Jira"? Or is there a different way to go about tracking something like this? Or should I not even be tracking these projects in my GTD lists?

Thanks
 
It's usually not worthwhile to duplicate groupware like bug databases into your personal gtd system. How you want or need to do your job is a big factor. An automobile mechanic might not put "fix first car today" on an @shop list, but he (or she) might have agenda items for vendors, errands for parts stores, or R&D Ford emissions system for stuff that is not handed straightforwardly by routine business processes. But if f it helps you to have a task like "Kill at least 5 tickets today", that's ok too. Or put it on your calendar. It's what you want to see when you need to see it.
 
I would use the name of the real project as your GTD project name, but also make use of subprojects. If your list manager doesn't allow subprojects, then make the subprojects the GTD project names.

If working through bugs only uses Jira and your computer I wouldn't bother transferring the actions into GTD system, it's unnecessary double handling. However if the bugs require multiple actions to fix (eg maybe you need to discuss some with a colleague), then they would be worth putting into GTD. You also might want to consider blocking out regular time in your calendar to keep up with these.
 
Tickets

Forgive my ignorance of your situation but if the tickets are already being processed and handled for you, why would you need to track them? Isn't the system doing that already for you? The only thing you'd need to take care of is when you need to take some action that you can't do immediately and for some reason can't put back into the system (in the form of notes/comments/etc.).

I have a tracker system for my site's tickets and basically we just use the individual ticket as the project and the discussion as the action reminders/triggers. (project support is another matter but it doesn't seem you're asking about that). It is its own project and self contained. Rarely (if ever) do those tickets cross over into any other realm of my life.

I do the same thing with email. I set up a GTD system inside my email system and it "tracks" itself; instead of trying to copy all my email to some kind of parallel system.

Just a thought.
 
Leave it where it happily lives.

mcogilvie;91619 said:
It's usually not worthwhile to duplicate groupware like bug databases into your personal gtd system.
Click to expand...

If you trust your bug tracking system do not duplicate its contents in your personal GTD system.

Just treat it as a separate @context list.
 
In similar situations, I've been known to print out all the stuff from the database and "import" it into my own system that way. That may or may not be practicable for you.

Cheers,
Roger
 
Answer from a software developer

I'm a developer that uses JIRA as well, so I understand your issue VERY well, and so far none of the answers here address it well (IMHO) Here's how I like to consider it. First, almost every issue I work on takes more than one step to complete. So they really are projects.

Given a ticket, "GTD-555 System crashed when user did something silly". I might create a "Goal/Project" called "Add support for silliness to system (GTD-555)".

This way, I'm focusing my work to complete the goal of fixing the issue. Closing the ticket isn't the goal, it's simply the last step in the process to the goal. I then do my thinking of what I need to consider to complete this. Those are items to drop in the project support so I don't forget them. Identify the very next action you can do, and add that to your list. When you finish that, you will probably intuitively work through the next actions needed. If you don't, refer back.

I also find that the notes I write down in the project, often spin out into their own someday/maybe projects if they aren't really needed to complete the goal in the end. For example, while fixing "silliness support" I notice that the system should also support "craziness," well then I add a someday/maybe project with notes of where I noticed it and/or some initial ideas. All so I don't have to "rethink" these items later.
 
john44helms;91663 said:
I'm a developer that uses JIRA as well, so I understand your issue VERY well, and so far none of the answers here address it well (IMHO) Here's how I like to consider it. First, almost every issue I work on takes more than one step to complete. So they really are projects.
Click to expand...

I stand by my answer, which reads in part "It's usually not worthwhile to duplicate groupware like bug databases into your personal gtd system. How you want or need to do your job is a big factor." If everything you do is non-routine and takes multiple steps, then you have projects. Depending on the functionality of the specialized software you use, you may or may not want to put additional information into it or a personal system. But routine is routine: if you spend 2 hours every afternoon from 1-3 helping to squash bugs, it's a calendar item. It all depends on how you work best and the nature of the job.
 
You must log in or register to reply here.
Top