JIRA Project / Component / Task Structure When Crossing System Boundaries?

Hi,

We are in the process of planning a JIRA/Fisheye implementation and are getting caught up in the different approaches could be taken with respect to project/task and component organization. In some ways I'm quite embarrassed to ask this as I doubt we are very complicated in the grand scheme of things, but here goes...

Ive tried to explain our situation as best I can below. It is quite long, so in summary:

I was hoping that somebody might be able to kindly offer their experiences or advise on handling situations where changes may span multiple system, and where there are different formalities of change request.

The long version is….

We are a team of 10 developers looking after ~50 systems. Our work consists of :

Small ‘business as usual’ (BAU) requests (eg, bug fixes / minor enhancements) that tend to come to us in an informal manner (email, phone, conversation)

Larger scale projects (referred to as internal projects from now on to differentiate from JIRA projects) that come to us in a more formal, documented manner.

BAU and Internal Project work can affect either single or multiple systems. Two simple examples would be…

Single System Change : Allow capturing of new data attribute to the trading system.

- Task : Database schema changes

- Task : New front end screen

- Deliverable : New build of trading system front end

Multi System Change : Build feed between Trading System and Fund Accounting System

- Task : Trading System : Extract changes to message bus

- Task : Fund Accounting System : Import notifications from message bus.

- Deliverable : New build of Trading System Backend

- Deliverable : New build of Fund Accounting System Backend

When we release software, we need to pass down a release ticket number. These are generated outside of our team (so cannot (for now) be JIRA numbers) and there must be one release number per system – ie, the multi system change above would have 2 release numbers.

We currently produce weekly reports to management (booo) that show the team activity for all our work. Project related report is grouped by project and then system, and the BAU report is grouped by system. (Note: The format of these reports can change)

As a starter for ten, our initial thoughts were to:

  • Setup different task types for BAU and Internal Project work in order to allow us to capture the different data associated with each (eg, Internal Projects have project codes and external priorities that would be good to track in JIRA, where as the BAU work is lacking this)
  • The 50 systems would be represented as components
  • Setup a Development Work project that contained all accepted development tasks regardless of system.
  • Single system change work would be handled the task/sub-task relationship. The sub tasks would be assigned single component to reflect the system, and the per system release numbers discussed above would be stored per sub-task.

- Eg, Parent Task : Build feed between Trading System and Fund Accounting System. Component: Trading System + Fund Accounting System

o SubTask : Extract changes to message bus – Component : Trading System

o SubTask : Import notifications from message bus – Component : Fund Accounting System

  • Multi system change work would be handled the task/sub-task relationship. The sub tasks would be assigned single component to reflect the system, and the per system release numbers discussed above would be stored per sub-task.

- Eg, Parent Task : Build feed between Trading System and Fund Accounting System. Component: Trading System + Fund Accounting System

o SubTask : Extract changes to message bus – Component : Trading System

o SubTask : Import notifications from message bus – Component : Fund Accounting System

  • Set up one project to act as an requests capture queue where the adhoc BAU requests could be placed prior to processing, rejection, acceptance, allocation, etc. This could be hooked up to a specific new-requests email address, or, ideally, we ask our the people making these requests to always make them via a screen so that we can ensure that a minimum level of information is included. If we accept a request, we will move it into the Development Work Project, linking it to components, possibly assigning to developers, and creating subtasks for the multi system related work.


Now, this seems to get us to a usable point, but there are a few things that smell bad.

  • Is this a misuse of components? Shouldn’t component reflect the subcomponents of a system (eg, Backend, Frontend, Database, etc). Given the high level (mis)usage, we cannot break down further into sub components

  • Is this a misuse of projects?
    • Should there be one project per system? This seems to be the way with the Atlassian systems on their own JIRA, but how would this work if a project crossed systems?
    • Should there be one project for all BAU work, and we create new projects for the longer running internal project work?
    • There would be repetition of the bespoke project fields across each of the project tasks.

We’ve thought about alternative approaches, but they seem to have other problems. The obvious one would be to set up a JIRA Project per System, but…

  • How would cross system changes be handled? I know we can link issues. Maybe we could create a parent issue/child-issue link relationship…. ?
  • If Internal Project tasks were scattered over multiple JIRA projects, can you see them all in one place? Can you report across projects?
  • Where would the container task live? Perhaps we could nominate one of the systems as an arbitrary home. Maybe we should have another JIRA project to house cross system work so that we can see them in one place… ?

Maybe the above plus the following plugins would be a good way to go, but I was hoping to stay fairly vanilla to start with

Multilevel Issues : https://marketplace.atlassian.com/plugins/com.almworks.jira.structure

Linked Issue Reporting : https://marketplace.atlassian.com/plugins/com.docminer.jira.issue-links

Another alternative we’ve considered would be to use JIRA projects to represent the Internal projects (rather than diff task types). The tasks would at least have a natural project grouping and it would be good to have dashboard metrics through the life of the project, but we would still have issues with representing cross system tasks, I’m not sure if it would be possible to perform cross project consolidated reporting (it appears that project cannot share components), and the BAU project is a an arbitrary catch all bucket. There would also be more admin involved in setting projects up (rather than simply creating a new Internal Project Task).

We are going to model a number of scenarios using various approaches and evaluate in terms of task setup, data repetition, ease of navigation, visibility of grouped items of work, and intrusiveness of workflow and report-ability, but any pointers would be greatly appreciated.

If you have read this far, many thanks for your heroic effort and for any help you may be able to provide.

Thanks,

Stu

2 answers

Hi Stuart, Some aspects of how to group issues with projects, components, labels are disclosed in this post http://blogs.atlassian.com/2013/11/organize-jira-issues-subcomponents/ Particularly dealing with issues which affects different areas each represented by separate jira project are addressed by Multi project picker plugin - http://brokenbuild.net/multi-project-picker/ Hope it somehow will help you. Vasiliy

@Stuart Holden I keen to know what you went with in the end?  I've tried a couple of ways previously and hit challenges.  We are currently in the same discussion regarding use of project or components to represent systems - I have concerns regarding projects per systems as I've done this before and things get missed, board filters become complex etc etc

 

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Jira

Meet the AUG leaders of Northern Virginia

@Rachel Wright (Jira Genie), @Billy Poggi (AUG NOVA, DC), and @Dana Jansen (Confluence Queen) are just some of the folks that lead one of the world's most active Atlassian User Group (AUG)....

123 views 4 9
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you