So you’ve got your team project configured to a fare-the-well, and your team is running like a well oiled machine, and you are able to see it. But then, the worst thing in the world happens. A task comes up, and you are wholly dependent on an outside team to complete it before you can proceed. How do you track this? How do you account for this?
This truly nightmarish scenario is what we’ll deal with today. The fact is, this situation is actually fairly common. No one team can do everything on their own, which means to some degree, we are all interdependent on one another. Understanding how to coordinate work when this happens can mean the difference between successful completion and needless delays and cost.
What you can’t do
Lets start with what you can’t do. The reason you can’t do these is that the associated things are limited to a project, therefore do not work for issues outside your project. In other words, JIRA itself will not let you do this. You can ask, but I cannot change these things any more than you can as these are built into the code.
The first is put it in a release within your project. Because a release is a project level config, you cannot put a foreign issue into your release. You can get around this for querying if the other project admin is willing to create a release in their project with the same name, but this solution will not let you use the project release tools to track that foreign release.
The second thing you cannot do is transfer a sub-task to the foreign project. As a rule, a sub-task and it’s parent MUST be in the same project. This is hard-baked into JIRA, so there is no way around this…directly. What you can do is use your subtask as a tracker in your project, and link it to the foreign issue. It’s not as direct, as stated, but it is the recommended method.
What you should never do
That being said, there are a few things you should NEVER do. In fact, they are considered two of the Seven Deadly JIRA Sins:
JIRA Sin II causes a problem because most teams here use some form of either scrum or kanban board to track their team’s work. If you transfer an Epic to their project as a request for work to be done, these Boards treat those differently by putting them into the sidebar on the board’s backlog screen. Here, they will be missed, which means your work won’t be done.
JIRA Sin IV is more a courtesy, but it is still sin worthy. Most people will at the very least move an issue some sort of closed status when completed, and may even include comments to explain details or ask questions. Skipping this will not only waste your time, but theirs as well. Even If you don’t see any activity on your issue, try putting in a comment and waiting a few hours before you march to their desks demanding an update. Maybe they had a higher priority item come in, or maybe they just haven’t gotten to it yet. Maybe they thought it was a lower priority than it actually is. However, stopping whatever they are doing right away so they can answer your questions that could have been handled by comments is not going to win you friends.
Well, what the heck can I do then!?
- Releases with the same name
- Pros – This is great for teams that use dashboards – as a query on only the release name will return results of all projects that share that release name.
- Cons – You lose all ability to track from a single project release view.
- Duplicate issue and Link
- Pros – This is actually the Atlassian recommended approach to handling this problem. It gives you visibility without directly interfering with another team’s processes.
- Cons – You actually have to watch the issue and followup on it. You may also have an issue updating the issue, depending on the other team’s permissions and setup. I Should state that this is generally not a problem, only in a few very specific circumstances, and we actively try to avoid this situation – but it does happen.
- Transfer story
- Pros – You get to craft the story how you see fit, and have it fully prepared before firing off to the other team.
- Cons – This can literally break another team’s workflow if you transfer it as the wrong issue type or wrong status. For this reason, this is not really recommended.
Watching issues, your ace in the hole
So, you’ve created a story/task/what-have-you for the other team to work on. Now what? How do you know when it’s done? The answer is simple, yet this is the biggest problem people seem to have. However, if you watch an issue, you can get JIRA to email you every time anyone transitions, comments, edits or even looks at an issue the wrong way.
This is your ace in the hole. You’ll know when an issue has been worked on, and conversely when it has not. This will then let you reach out and maybe post a comment asking “What’s up?” As a rule of thumb, you should always watch issues you are sending to another team.
If there is one thing that will help get eyes on your issue and get an early ETA on it, it’s a simple “Heads Up”. Reaching out to the project owner on chat saying “I just submitted XYZ-1234” with a link can help make sure it’s seen, and make sure the other team has all the info they need to proceed. While a simple step, most people neglect this in favor of just dumping it into a black hole of a queue. Don’t wait for a problem or an issue to be ignored, just reach out! It will save both your team and their team time in the long run.
What it really comes down to
The great myth of JIRA is that it will do the work for you and make your life easier. While it can make life easier, it merely provides an platform for you to organize your work, share it with others, and submit work requests to others. It is still on you to do the communication, the followup, and the work, and this is no truer than when you have to work with another team. JIRA will give you place to submit the work, but it is on you to do the legwork required in following up and making sure it’s done. But use the tools it gives you to help! Write comments! Watch issues! Give the other team a heads up in chat when you submit an issue! All this will make your next collaboration project a success.