nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practice of handling task dependency between two teams

Gautam De

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?

Accepted answers

Bill Sheboy

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,

Bill

All comments

Dirk Ronsmans

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

Bill Sheboy

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,

Bill

Gautam De

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,

Gautam

Gautam De

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,

Gautam

Bill Sheboy

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud