I want to create a project in the JIRA.
The project should be able to select the type of work and choose another project.
I wish user can create selected another project because there are many large numbers of projects.
and type of work can choose two or three depth.
First.
type of work use customfield.
choose another project use component.
-Team member should be an administrator permission in project.
Second
type of work use customfield.
choose another project use label.
Is there a better plan?
Last I want to know difference between label and component and version.
I think user can create label and project admin can create label, component, and version. The label applies entirely. But component and version applies project.
It sounds like you may be trying to do something which I don't think is possible: an issue is in exactly one project at a time.
Components are a lot like labels, but are selectable from a set defined for a project. It can sometimes be useful to define components which align across multiple projects. You're correct that creating components requires admin privileges, while anyone can create labels; this can make for an excess of different labels if they aren't used with some care and discipline, but the components list will stay as clean as the admins keep it. An issue can relate to multiple components and have multiple labels. Sharing labels or components across projects may achieve what you're after.
Because components are a "privileged" class of labels, it's often wise to spend a bit of time considering a sensible scheme for them based on the anticipated breakdown of issues; changing them in bulk midway through a project can be tedious.
I'm less familar with versions; I'm not sure whether an issue can be linked to multiple versions. They are usually used to group issues for release planning, but that isn't imposed by the tool, they could be used for something else; it might be confusing for users making assumptions about what "Version" means, though.
It's difficult to answer your question, as there are some grey areas, but will try to briefly explain the difference between labels, components and version.
Project and components
First of all, a project is (a project) a collection of issues (stories, tasks, bugs, etc.), so components are just sub-sections of a project. They could be either defined based on the architecture of your product. Also, a component can be assigned by default to a particular user or group. An example of components could be database, UI, notifications.
Labels
Labels help you categorise and search for an issue and have the advantage of allowing multiple labels to an issue.
Versions
A version is a set of stories and bug-fixes and helps you plan the release of those stories and fixes to the customer.
The main way to categorise the type of work within a project is to add different types of issues and for each one define custom fields, screens, and workflows.
Hope that helps you address the problem!
Related
I am to set up Jira in my organization and there arise some questions, for which I could not yet come to a, for me convincing, decision... may you give me your opinion, what the best configuration would be?
(I will be talking here about projects but it might be found out, that should later be boards or whatever)
I have requested my org the creation of a Jira account for my department, and as seen from the settings, I got created a Board associated to me as an admin
We are a team of 15 people in the department
We want to start setting 10 different projects, some might be related to the other ones but still keep an individual sense, thus, each should have its own Backlog
The scheme of the projects should all be the same (notifications, workflow, issue types...). Ideally, if changing something lately in the scheme, all projects should actualize to this automatically
We will be all teammates allowed to work on all projects within the department, always, no restrictions
We want all to be able to check for the statistics etc. related to any project in the most easiest way
Users want to have on their board (screen) all projects and tasks, in the order planned for them to be performed, don't matter if they belong to different projects. Desired view would not be a flatt Kanban but issues being classified by Project > Epic > Sprint
The ideas I came up with are:
(1) Me --> Board --> 1 JiraProject --> n Epics (each = OurProject)
Having just one project (namely, the name of my department) and then create one Epic for each "real" project we want to handle. Then, to each Epic create the Issues related to each of our real projects. The problem with this is, that we would need a second level of Epics to suborder into each of the main Epics (representing our real projects) so that we can group their issues into logical parts of the project. This second level of Epics seems to me not to be possible. Additionally, this approach will just provide us with one Backlog common for all our projects (here provided as Epics).
(2) Me --> Board --> n JiraProjects (= OurProjects) --> each JiraProject
This seems to me to be the best approach, but has the inconvenience, that when a person has to work on several projects he has not the insight of the order of the tasks he has to perform, nor if any of these collide in time with any other of any project.
I ended up creating a single Project with a single Board.
In Project Settings (left side panel, bottom):
I enabled Components to appear on the left side panel
I set Issues to show the field "Component" when they are created
The Jira logical classification will be now like this:
PROJECT is my department
BOARD is the common view all users will share
VERSIONS are Versions
EPICS are my different Projects
COMPONENTS are now a kind of Epics for my projects, but with the disadvantage that:
a) they are all shown in a separately view, not as a side panel similar to VERSIONS and EPICS
b) they are all listed straight forward, which requires to give an identifier at the beginning of their name to differentiate to which Project they belong to
USERS: all Users will manage to see the main Project (which is my Department) and inside of it, all the Epics (which are my Projects). This was initially my requirement, so it is ok.
I wish Jira was a bit more flexible on letting us creating some additional group categories similar to VERSIONS and EPICS, so that we could get and extra group layer.
The use of Components here is not really very useful, but also confusing and not intuitive, but is the only option available at the time of this post to extra group somehow my Issues.
Problem:
Customers that become access granted, can access and see all or projects, what is naturally not good!
Trying to figure out best way to setup Jira for cross-organizational project. We have a Continuous Delivery Program that will split off into separate backlogs to be worked by different teams based on Themes.
Wondering if we should setup one project to manage the overall high level project, and then different projects per theme of work that will be managed by the individual teams.
Are there ways multiple teams can work out of the same project but track their work separately (including if their work is Kan-Ban, Scrum-Ban or Sprint based?)
Regarding the question in the title. It's possible to move issues in JIRA from project to project. This feature is quite handy and you even can do bulk operations. See Moving an issue for more details.
Regarding structuring your projects. Out of the box there is no feature in JIRA to create such a workflow with projects and sub projects you have described.
A possible workaround could be using components as sub projects.
In this case you would create a project which act as your high level project and divide this project into several components. For components you can add a lead, do versioning but you can not set security permissions based on components for example. So this is not a perfect solution and have indeed some limitations since components are not projects. But you have to evaluate this approach by yourself if it is sufficient for you.
Another option would be to use a plugin e.g. Structure. I am pretty sure there are even more out there which promising to solve your problem. From my experience also using a plugin may be not the silver bullet you are expect. You have to evaluate it first if it really suits your workflow.
For the scenario you describe, the issues that you start from are probably more high-level than the actual work that has to picked up in the separate teams.
What I find to work well, is to keep 1 project (ie. Opportunity Backlog) for the high level issue (ie. an Opportunity) and when an opportunity gets detailed out, just create issues in the projects of the teams that will work on them. You can still link those issues to the opportunity so people who look at it can see what is happening in each team.
Another option is to keep everything in 1 project, but to make the relevant issues show up on the board for the team that has to work on them. A board can list issues of multiple projects. You just need to update the JQL query for the board accordingly. For more details, check the documentation. Note that working with sprints can get cumbersome if the same issues are listed on boards of multiple teams though. Best to configure things such that an issue is only displayed on the board of 1 team.
I wouldn't bother with moving issues too much. It's not a very user friendly action.
We have the full Atlassian product range and I am looking at how to make best use of it
We are using Stash to manage our Git 1000+ repositories all of which contain tags pointing to their versions.
I need to be able to define how our software versions depend on each other
For example:
System_x.y.z in production consists of
group_of_components_a_x.y.x consists of
component_a_x.y.z
component_b_x.y.z
...
System_x.y.z is release candidate_a consists of
....
System_x.y.z is in regression test
...
System_x.y.z is in performance test
...
System_x.y.z development is being tracked by Issue#
...
etc etc
I have been using ClearQuest to achieve this but would like to move to a pure Atlassian solution if it exists
I would also like to define a name for group_of_components so that I can attach owners to it as well as to components so we can use them elsewhere in the workflow.
can notify them when versions change.
In Issues so I can see when different teams are working in the same areas
I would also like to be able to use the System_x.y.z, group_of_components_x.y.z and component_a_x.y.z
In Defects so I can see where the error was found (System_x.y.z, group_of_components_x.y.z)
In Defects so I can see where the error was fixed (component_a_x.y.z)
Is any of this possible?
Is any of this possible?
The short answer is yes. It's all possible.
Jira has the following hierarchy:
Project
../ Epic
../../ Task
../../../ Sub-task
If you need to track version numbers as part of a product roadmap you need to use Projects for that feature. There are probably other hacky ways to use labels or components to do something like this but you will spend endless hours extending these hacks throughout Jira. Not a fun exercise IMO.
I need to be able to define how our software versions depend on each other
Dependencies can easily be added at the Epic/Task/Sub-task levels but I'm not aware of an easy way to do this at the version level. I'm only really aware of the Agile Cloud solutions. If you install this locally I'm fairly sure you could find a way to do this if it is truly needed.
I would also like to define a name for group_of_components so that I can attach owners to it as well as to components so we can use them elsewhere in the workflow.
It's very easy to name all issue types and projects. Projects have an owner. All issue types can be assigned to any user (with access rights). Additionally you can add users to the "watch-list" of every issue.
can notify them when versions change.
The watch-list will notify all watchers by email. Additionally you can set up workflows to reassign or marshal each record through a custom workflow.
In Issues so I can see when different teams are working in the same areas
You can add users to teams in any combination (users can be on multiple teams) but I'm not sure I fully understand what "areas" means. You can search, filter and report on all issues by team(s) if that's what you mean.
I would also like to be able to use the System_x.y.z, group_of_components_x.y.z and component_a_x.y.z
In Defects so I can see where the error was found (System_x.y.z, group_of_components_x.y.z)
In Defects so I can see where the error was fixed (component_a_x.y.z)
Each bug you define:
can be organized into an Epic
can be associated to any number of tasks (Blocks task 1 or is blocked by task 2, etc.)
has one or many "affects versions" to track where the bug occurred
has one or many "fix versions" to track when the bug was fixed
My company started using JIRA for issue tracking two years ago, and we have struggled with optimizing the workflow for it since. The main problem is that we have a number of modules and libraries that are shared between different products, whereas JIRA has a "silo" view of projects. Basically, JIRA is fine for tracking issues from a "customer project" point of view, but I started to see it as more and more useless for a "back-end development" point of view.
JIRA's components are not good enough for my needs, since the developer of the module or library cannot correlate the issues appearing in different projects for her module and assign them to different versions of it. What I need is a hierarchy of projects, where a component in a higher (product) level project relates to another project at a lower (module) level.
Atlassian seems to be unwilling (unable?) to add such a feature to JIRA, despite numerous related issues dating back up to nine years. Moving to another issue tracking software that has this feature (if there exists any) is not feasible for us at the moment, though.
Judging from the number of replies on the related issues in Atlassian's JIRA system, we can't be the only company with this problem, so I would like to know what other people are doing to get around it.
My current plan is to use components for the product projects, and automatically create and link clones of component issues in the relevant module/library project. Clones are sub-optimal, since they are not as strongly linked to the original as I would like, and they double the number of issues in the system (or more, if the issue in the module project needs to be duplicated in other higher projects, say, if the fix would break the API or if it was a critical issue that any user of the library should be warned about), but I'd like to keep the original, since after fixing it in the module and closing the module issue, there'd be more time needed for integrating the fixed module into the product.
I have found plugins that allow post-functions on transitions, e.g. "CustomWare JIRA Utilities", so that should work for automated cloning, linking, and updating, although I am not 100% sure.
What is missing, though, is a good way to manage the dependencies between the different versions of products and modules (i.e., version X.Y of product A uses version I.J of library B), since versioned components are another thing that JIRA doesn't do.
Any better ideas?
I would treat reusable components the same way they're treated for distribution (e.g. DLLs), as separate projects in Jira.
Track your issues against the affected version of the module. You can always move an issue between projects if it's discovered to be a different part.
This won't help maintain cross project mapping (I.e. System A v1.3 requires Component B v2.7) but it becomes simple enough to dump in a Wiki.
Another approach is to create your own multiselect custom field, make it valid across multiple JIRA projects and use that instead of the system components field. You would lose the ability to automatically assign issues but gain the ability to use "components" that are valid in more than one project.
~Matt
OnTime uses a tree-based structure for projects, allowing you to open a filter to view descendents as if they were on the current branch. I don't know if that is much help for you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
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?
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.
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.)
I would match up the components with your modules/artifacts/jars, so each issue can be owned by a particular module (though it might have dependencies/relationships with others as well).
If you can make a strong case to have finer grained issue management than the module level, consider why you wouldn't also separate the associated module.
Having this 1-1 mapping helps clarify your release schedule, you can easily what issues version X of your project has, and which modules to focus the effort upon. It also helps simplify associations between Jira, the build system, and the SCM, e.g. if you're using Bamboo you'll likely have a build project per module, so you can simply add the association.
As of 4.2.4 it is not possible to version components, only projects. Keep that in mind if you like to use the road map feature.
There's a long-standing (7+ years) request to add versioning for components:
http://jira.atlassian.com/browse/JRA-3501
Create a component for each major module, or maybe even system tier (eg Backend, Frontend). I wouldn't go below-module-level granularity.
You may add components for supporting activities, such as BA, Testing (agreeing with mdoar)...
Components are orthogonal to versions/releases
I've got another take on components now.
With customers I refer to the Components field as:
A multiselect field that's useful for automatically assigning issues. Each of the things in this field has a potential assignee associated with it.
and then I say:
If you don't care about automatic assignment, just treat the components field as a convenient system field.
So to answer the original question again, ask yourself if you assign issues by team or by the fine-level you referred to?
Probably the former.
JIRA designed to have every component of project to have same set of version numbers, so if you want you components to have independent version numbers you either need to set up a different project for each component or use a plugin developed by me that allows component specific version numbers and at the same time allows grouping of components into a bundle. The plugin is "Component/Subcomponents/Bundle Versions for JIRA" and available at Atlassian Marketplace. More information is available at atlassian plugins help page. Another option is to force every component of the team to have the same set of version numbers. Otherwise it is very difficult to select correct version numbers for components.
We use a 2 level component hierarchy (thanks to greenhopper ...) - Themes and Epics. The build in Greenhopper Themes and Epics don't let us aggregate and report the way we want, and this does the trick pretty well.