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.
Related
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!
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.
I'm looking for a work-item-tracking/bug-tracking system (or JIRA plugin, or TFS plugin, or...) which makes it easy to stack-rank work items without having to manually assign priority values to each work item.
Instead, our team wants to be able to see a list of open work items and be able to drag-n-drop one or a multiple selection of work items until the order matches the team's prioritization. This would be much easier than arguing about priority numbers and dealing with ties (e.g. "which of the 5 bugs marked priority=2 should I work on today?").
Our team is considering switching work-item-trackers (we use Gemini now) and availability of a good drag-n-drop prioritizer is high on our requirements list.
I realize drag-n-drop ranking is non-trivial because no team will stack rank all work items. Instead, we'll want to take a subset (e.g. work items for one sprint sprint or iteration, or bugs assigned to one developer) and stackrank those, then later look at a different subset and stackrank those, etc. And I'm sure we'll sometimes need to mix and match different stacks, so there'd need to be heuristics (ideally configurable) about how to show a stack of items previously stacked separately.
Pivotal Tracker is close to the drag-n-drop UI I'm thinking of from a UI perspective, but Pivotal's model of separating user stories from the underlying work items (plus a few other issues) doesn't match how we want to work. We don't want to have to deal with different artifacts (stories vs. JIRA/BugZilla work items)-- instead we just want a drag-n-drop UI to automatically fill out a "priority" field in the issue tracker, and which we can use later when sorting and filtering. And we wouldn't want to use Pivotal as our only work item tracker, because it seems to lack common features like bulk editing which are critical for large projects.
Anyone know of a tool like what I describe above?
Urban turtle is the best TFS add-on, making ranking/prioritizing a sane activity. Priority by number is a disaster so don't think you're alone there.
http://urbanturtle.com/
Urban Turtle is updated every month and used by quite a few teams including a number of my teams.
Eylean Board has what you are looking for. They offer a task board where the tasks are prioritized by moving them around, the priority tasks being on top. Interface is nice and clean and they offer other features such as integration with TFS, reports, etc.
The greenhopper plugin for JIRA has this feature. It's worked well for me ...though I'm not a big fan of JIRA in general.
http://www.atlassian.com/software/greenhopper/tour/backlog-management.jsp
Previous to this, I just used excel.
One of the best (and fastest) web UI's I've seen is on AgileZen, which supports something similar to this. Last I knew it did not have built-in integration with TFS, but it does have a REST API. It's basically a web-based, shareable Kanban board.