I am the QA lead for a company that has multiple teams with their own projects in Jira. Is there a way I could track Jira tickets from for example, the engineering board or bug board in the QA board so I can assign those features/bugs to QA team members to test?

  • 2
    You might try creating a board with filters and bring in cards from multiple projects with JQL. Some questions though. Why do you have a QA board? And a bug board? Normally you have a board with steps and types of tickets. And why do you need to assign tickets to QA team members? Doesn't each team handle this with their own QA engineers?
    – Bogdan
    Commented Nov 4, 2022 at 21:32

3 Answers 3


1° you need the right authorization en each project

==> comment ? edit ? view ? assign ?

you jira admin as many way to do it.

==> create a "QALead" rôle ==> give each needed authorization to this role in auth scheme of each project ==> give this role to your account in each project

2° with this you have now an access to the issues ticket. You need to select the right selection of ticket

Create a filter.

How did you recognize wich issue in each project is for you ?

Let discuss with other members of teams ;) Why not by a tag or a status in workflow ?

3° create a board to let it more readable. Base your board on the filter.


Short version: yes.

Long version:

Jira is based in 3 key concepts that new users oftentimes struggle to understand:

  • Projects
  • Boards
  • Cards

To illustrate this, I like the library analogy:

  • Each project is a library.
  • Each book in this library is a card.
  • Each shelf is a board.

You have different libraries: math, history, geography, philosophy, physics, chemistry.

Here comes the tricky part: the shelf is dynamic and can show any book you want - from any library - although it's physically "appearing" inside one single library.

So, you can have a "XXI knowledge shelf" inside any library. It could (if you want and configure accordingly) show math, history, physics, all at once.

Likewise, you could have a "Newton shelf" and it would bring items from physics, philosophy and chemistry libraries.

Still, the books are unique and belong to a single library. It means that if someone using the "Newton shelf" writes a note into Optiks book, someone looking at this same book in the "XVII knowledge" shelf would see the note.

Books and libraries are unique. Shelves are "views" on top of these books and libraries.

Back to your case:

You just mention boards and that each team has a project. It's implicit whether "team" is QA team or Alpha team composed of QA + Engineering. Hope the analogy above helps you to adjust it to your reality whichever it is.


FWIW, yes you can. The important things to realize here are:

  1. Boards can span multiple projects (simply update the JQL filter in the board settings to include whatever projects you need to.
  2. Issues can appear on any number of Boards, provided they match the filters for those boards.

As an example, I recently configured an engineering workflow that utilized 3 boards: Engineering (backlog and sprints were managed from this one), QA (this was essentially a kanban board fed by the Engineering board), Release (release planning and management was done from this board, and it was fed by the QA board), and Managment (surfaced Blocked, overdue, failed QA, etc) boards.

The proper order of operations for this IMHO is to

  1. Understand and design the actual end-to-end workflow that your entire organization will be using. Team involvement is super helpful at this stage.
  2. Identify your core functional groups (e.g. are your engineers also doing QA? Do you have an automated CI/CD pipeline or are those managed by a team, etc)
  3. Determine which statuses each team should own (map 1:1 to columns on that team's board), be informed of (those can be combined as appropriate into broader columns on that team's board, e.g. "In Progress" and "PR" status may appear in an "Upcoming" column on the QA board, while "QA", "UAT", and any statuses to support staging releases may be combined to a single "In Review" column on the Engineering board), and not be involved in (e.g. "To-Do" or "Blocked" doesn't need to show up on the QA board")
  4. Build your boards based off of the last step.
  5. Document and provide training for your development process.

Just my 2 cents. Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.