Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best practice of using components in jira projects [closed]

Tags:

jira

We are using Jira heavily in our day to day development. I'd like to see if there are any best practices in creating project components in Jira?

For example, in your opinion, is it better to create a component for each development module in Jira or maybe finer-grained components are preferred by your team?

like image 916
ashkrosh Avatar asked Aug 02 '09 16:08

ashkrosh


People also ask

How Should components be used in Jira?

Components can be used to group issues into smaller sub sections, like UI, API, Hardware etc. You could also use it to organize your issues based on customers, areas, functionality etc. I use it to organize tasks base on the tool, its a quick way of for example see all my tasks that I have related to Bitbucket or JIRA.

Can Jira components be shared across projects?

There are two options for sharing components across projects in Jira: Creating components with the same name across the projects manually. Use Jira app to synchronize components automatically.

What are 3 good practices when using a tool like Jira for software development?

A Jira workflow has three basic components: statuses, transitions, and resolutions. Best practices for Jira workflows include keeping your workflows simple, not edit live workflows and not confusing “resolution” with “status.”

Is there a limit to components in Jira?

1 answer. On the trial license, you can have a maximum of 25 components per page. For paid plans, the limit is 1100.


2 Answers

Components are like little sub-projects. Projects seem to be most useful when they group people together. I recommend to my clients that JIRA projects reflect the social organization to some degree, at least until the number of projects becomes very large.

Also, avoid the use of a component named "Misc" or "Other". They tend to become waste dumps of issues that no-one cares about.

like image 81
mdoar Avatar answered Oct 13 '22 11:10

mdoar


Most important about components is to be unambiguous and not too many. In our team now, we are migrating to 3 level hierarchy (in GreenHopper sense):

  • on the top level you have the BA components which are few and delineated by team (infra, backend, GUI) - this helps BA guys route the request to the correct DEV-team manager assigned as component lead.
  • the second level is actual process (in the Unix sense). This is very clear definition. In case an issue maps to multiple processes, we assign it to one of them (BTW, GreenHopper does not allow multiple leaf components, but plain JIRA does). This is done by DEV manager.
  • the third level is optional and rarely used, denoting subsystem within the process. We use it when a considerable part of the of the issues are related to a well defined part of the code and we want to track them separately. This is usually done by the developer working on the issue.

In order for such progressive refinement to work, you need to have idea of who is assigning to which component and who is processing the issues assigned to it. The latter is denoted by Component Lead, the former is not explicitly supported by JIRA (or we would be able to say that BA's see only their components, DEV managers, only their subcomponents + all BA, etc.)

like image 32
ddimitrov Avatar answered Oct 13 '22 12:10

ddimitrov