Accurate reporting

[Perry Wong]

The way our projects work is that issues sit in one project, being worked on by one team. Then it gets thrown 'over the fence' to another project, which then works on it (doing something different to it). This goes on until the item is published on our website.

However, it also means my reporting is off, because the team that completes the work has the status 'done' assigned, listing a lot more 'done' projects (and amount of work conducted) than other teams, as their project doesn't effectively show existing (or historical) tickets.

Is there any way to track this?

[Bill Sheboy]

Hi @Perry Wong 

If the different teams are performing different work specifics to deliver value, why would they use the same Jira issue / work item to manage their work?  That approach may not align well with some of the built-in reporting for Jira Cloud.

An alternative approach for what you describe is to have a "parent" work item for the overarching request, and "child" work items for the ones the contributing teams perform.  This parent / child relationship in Jira may be implemented explicitly with things like Epics and Stories, issue links, Jira Product Discovery with Ideas and linked "delivery issues", etc.  Each of these methods has different ways to synchronize work, and perform reporting and overall progress tracking.

I suggest discussing the problem you are trying to solve with your Jira Site Admin to learn which of these, or other approaches, may help your teams better.

Kind regards,
Bill

[Stephen_Lugton]

@Perry Wong Rather than trying to change the way you track the work, you could create an automation to:

1. Check when the issue status changes to 'Ready for next team' (for example)
2. Clone the issue with appropriate fields into the next project
3. Move the trigger issue to Done

This would then show the Done work for each team whilst still throwing the work over the fence.

---

Note that you would have to adjust each project workflow to add in the 'Ready for next team' status at the appropriate point, and when the issue is cloned set the clone to the status it would be in if you had just thrown it over the fence.

You would probably also need to do a short training session / video / document to explain the new way of working

[Sebastian Krzewiński]

Hi @Perry Wong 

For me it sounds to use BI tool and analyse ticket changelog to get moments when ticket was moved to other project.

Regards,

Seba