Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Best practice of handling task dependency between two teams

I am part of a central data layer team of our org.

Many teams consume the DB objects and related APIs for data we manage.

Currently when any team needs any new DB object or API, they create a Jira story or even a Sub-task on their Board and label that with 'DataGroup'.

I have a Board which uses a JQL to retrieve such Jiras from other Boards.

Question is: Is this the recommended way to handle such dependency?

Or consumers should raise Jira on our Backlog when they want something from us?

2 answers

1 accepted

0 votes
Answer accepted

Hi @Gautam De 

Ignoring Jira for a moment...

  • Your central data layer team appears to be a service team...
  • Providing services to multiple other teams (requestors)...
  • And you want to manage the dependencies between requestors and your service team.

How you proceed may depend upon how your team works, particularly with intake and support.

  • For example, do you have a defined intake with requestors?  Doing so helps your team understand their requests and requesting teams understand the capacity of the service team.  Otherwise you could "over promise and under deliver".  Using a defined intake has the added benefit of requestors explaining the value of requests, helping you prioritize.
  • When you deliver something for a requestor, is it "done done done" or does it require participation together during testing and implementation?
    • If it is done, you do not need to see anything on the requestors boards, right?
    • If you need to participate with them, you still may not need to see anything on their board.  Instead, each team could manage their own work, and regularly interacts until completion.  For example, attending each other's stand-ups, planning, change management, etc.

Once you understand some of the above issues better, you can decide how to make any shared work between the teams visible using tools like Jira.

Best regards,


Thanks a lot Bill. You have nailed it.

We are yet to come up with a proper intake process - our shortcoming and refusal of consumers to follow a defined process.

We are trying to pivot on Jira to obtain their ask - otherwise it's through phone or chat only and it naturally results in change and re-work.

Some of the consumers have started to create straw man version of Jira on their Board which we are trying to change to ask them to create the Jira on our Board so that we can create analytics easily.

Best regards,


What can help is discussion and shared understanding with your stakeholders (requestors and customers).  There are always more valuable things for a team to do than the team has capacity to complete.  Helping people understand that idea is key to partnership.

To guide that, consider sharing your team's ideas of what "urgency" means (e.g. classes of service, severity / priority, etc.) and how much capacity the team has per time unit.  You may use shared ideas to create an intake process which makes sense for the team.

0 votes
Dirk Ronsmans Community Leader Jan 10, 2021

Hi @Gautam De ,

While i find your approach creative this really seems like it should be handled more strict through a JSM project.

When a consumer requires something (access/creationf of something new/..) that should all be audited and logged through appropriate channels. 

Right now what you are doing doesn't seem to be more than if they were sending an email to a shared mailbox asking for something.

Within a JSM/JSD project you would be able to create Request Types linked to a Service Request so that when a consumer/customer requests something the ticket will be created for the Agent to analyze and triage. Depending on what they require additional approval might be needed from ISO, DPO, Management,..  and all those approvals/requests are logged and managed centrally.

Afterwards you might even go in to Change Management which would then generate a story/tasks to build something or just remain in the Service Request for trivial items.


TLDR; So in my opinion your method is creative and seems to work but if you want to be more structured you should really consider a more ITSM minded approach (Request Management) inside a JSM project

Thanks Dirk for sharing an entirely new perspective. I

I must mention, implementing such a big shift in our operation it out of bounds for me. That said, I am noting it down and will keep in mind.

Best regards,


Suggest an answer

Log in or Sign up to answer
Site Admin
Community showcase
Posted in Jira Software

Presenting the "Best of 2020" Jira Software roundup!

Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...

7,184 views 8 28
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you