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.
Related
I am doing automation on over ten products. In jira I am using Kanban style workflow where there is no sprint and work sits in a Kanban board. I want to make dashboards for the different projects. The first problem I am running into is that I have lots of different breakdowns I would like to look at and I am running out of room on my dashboard. It says I can't use any more gadgets on my dashboard. I would like to make several different dashboards for a project for different categories and I would like to group them together. Then I want to do this across over ten projects.
Jira is not a data visualization tool so don't expect too much out of it, My suggestions is to not overcomplicate, are all this gadgets really that useful?, if yes the simple approach would be to at least organize them using a naming rule, for example Project-Strategic-week-performance.
Maybe a plugin like this one can help you with the organization: https://marketplace.atlassian.com/apps/1217625/dashboard-folders-for-jira?hosting=server&tab=overview
But overall try no to force a tool for what it wasn't made for because you are going to need a lot of effort and not getting the best results.
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.
I want to know best practices for creation of features.
Normally Visual studio extension creates feature for each web part.
Or it good practice or we should create 1 feature for multiple web parts in one WSP?
I don't know of any best-practice, but I can see two ways (I can think of) of looking at it:
When you separate your webparts into several features, you have the possibility to activate/deactivate the different webparts at will. If one webpart has an error you can just deactivate it. When one webpart fails compiling, you still have the others running smoothly.
The downside is that you "clutter" the Sharepoint Interface, because you have to manage several Features instead of one. That goes for activating/deactivating as well as deploying/retracting.
If you have one feature it is all of the above, just in reverse. You only have one feature to activate/deactivate, which makes it faster to manager. But if that one feature fails in some way (or any of the webparts within) you can only deactivate the whole thing. The same goes for deployment/retracting. When one webpart within your feature fails you have to retract the whole thing.
Whether development is easier or harder depends on your preference. One might say that it is harder to keep a consistent configuration in one huge feature deploying a multitude of webparts, workflows and master pages (where was the entry for that workflow again? ah yes, in line 1112) - on the other hand you have everything in one place and don't have to search in several features.
I would really make it up to your personal preference. When you are deploying a Solution to a customer, the customer is certainly more happy to click/install/deploy the "MyCompany Super Solution Feature" instead of several smaller ones, in the end you don't install MS Word with several setup.exe's (and then again, you can choose what features of Word to install...)
It basically depends upon your requirements.
By the way, this problem is resolved in VS 2010 extension