How I plan on integrating gtd with my team's Jira board

[Guðjón Geir Jónsson]

I've recently started setting up a gtd system for myself. I decided to use Todoist to keep track of my actions and projects and I'm leaning towards either Evernote or org-mode for general reference but am undecided.

One of the problems I'm facing is how to utilize gtd with my team's Jira board. I work as a software developer and every task my team needs to finish is a ticket is placed on a Jira kanban board.

So the general flow for me when working on a ticket is:

1. Move a task from Todo column to In Progress and assign it to myself
2. Sometimes tasks require some strategizing with another developer. Sometimes these meetings are ad-hoc and sometimes these are cross-team communications that require booking a meeting but that is rare and usually happens before the ticket is "actionable".
3. I just start work on the ticket.
4. When I've finished implementing the code change I put it up for peer review and tag some coworkers to read over the changes. This is done with GitHub's pull request feature which tracks the status of who has made comments or approved the code change etc.
5. After receiving reviews, depending on approval status, I either:
   1. Given that the code change was approved merge to master and deploy
   2. Reply to comments, answer questions, clarify etc.
   3. Edit code based on the review feedback (go to step 3)
6. After the code change has been deployed I move the ticket to QA column in Jira
7. If the QA passes the ticket it is moved to Done column, otherwise it is moved back to Todo column with a comment on what failed (move to step 1 except it's already assigned to me).

Now how I plan to translate this into gtd:

1. After assigning a task to myself create a project in Todoist with the ticket name and link.
2. If I need to book a meeting I either do that right away and that goes into the calendar or if I cannot yet I create a task with an Agenda label.
3. Create a task named "Work on implement X" or "Find fix for bug Y" with the WorkComputer label. Most likely schedule that for today because I'm probably going to start right away.
4. Create a task "Wait for review" with WaitingFor label and a link to the pull request in GitHub.
5. Replying to comments or merging is I would usually do ad-hoc because it takes so little time but if not create a task. If I need to make some changes I create a task to do that like in step 3.
6. Create a task "Wait for QA" with WairingFor label.
7. Rinse and repeat.

What has been my biggest problem is the context switching required when multiple tickets are between the Todo and Done columns. If I'm waiting for review, haven't gotten to answering a review and am deep into some current task that I find hard to set aside for a moment then sometimes things are forgotten and have to wait for longer than necessary to be adressed.

What I'm hoping for here is to get some feedback from the more experienced gtders on what they think of this and if they have some pointers that I have not thought of.

Cheers!

 

[Gardener]

I'm responding to this more with kanban thoughts than GTD thoughts, so I may be off topic.

Does your team have any goals with regard to reducing work in progress? Maybe there are too many active tickets?

I realize that you might say, well, sure, it would be nice to work on fewer things, but this is reality and you're not going to sit idle, refusing to pick up a ticket, just because you're waiting for a review of existing tickets.

But at the team level, is there a way to work on fewer things, faster? If everybody has fewer tickets, can they do their interaction faster because they're less distracted, and therefore everybody has less wait time for reviews, and thus less idle time, and thus doesn't need to pick up more tickets to fill that idle time?

 

[PeterByrom]

Hi!

if I understand you correctly, you seem to be saying that the main issue is how to stay on top of the reviews that come in from other people? In your example, you talk about being in the middle of a task that you find hard to stop, and then you fear that you will forget about and miss the reviews that have come in? Is that accurate?

If so, then how do you get notified when a review comes in? Eg do you get a notification in Jira? An email etc?

it seems as though you want to get the right balance between batch-tasking and minimising wait time. Constant interruptions will mean you take longer on the deep thinking tasks, but then you don’t want the ball to get dropped with getting back to peoples reviews.

depending on how to get notified of an incoming review, this will affect what the solution is. Eg you could have a rhythm or routine whereby you spend a certain amount of time in head-down coding tasks, then take a break, then respond to reviews?

It reads as though your Todoist is setup to be able to tag tasks and thereby batch your next actions by context. Is that how you have it setup? Ie: a project becomes an actual “project” down the lists on the left, and the next actions for the project are stored inside it and tagged with their context?

If you could get back to me on those questions then we can look more into this.