I am working in a big company and we are having a lot of JIRA projects, I would like to have a dashboard or a way to know if the projects that exist in JIRA are used, e.g if there are any issues in them (I don't need to see the issues just to have a number).
Can I do it without accessing to the database, do I need a plugin, is there a functional way to get the info? :)
thanks a lot
best regards
Adrien k
You can easily do this with the built-in Two Dimensional Filter Statistics gadget:
first, search for all issues in your JIRA instance. There may be an easier way to do this, but you can certainly use JQL like project=ABC or project != ABC.
save the search as a filter
go to a dashboard, add a new Two Dimensional Filter Statistics gadget. Select your newly-saved filter, select "Project" for one axis, and something small in number (like Issue Type) to the other axis. You'll also need to adjust "Number of Results" to exceed the number of issue types in your system.
save the gadget
Note that the Projects gadget also provides somewhat-similar information with fewer configuration requirements, but as far as I know, it doesn't show the numeric issue totals unless you hover the mouse pointer over the bars.
The company I work for makes a plugin that can do that - Structure
That's an example structure containing all issues in available projects, they are then grouped by project, and there's a column showing the number of sub-items (issues) in each group (project).
You can also add a structure to a dashboard/Confluence page.
On a large JIRA instance it be a bit on the expensive side to use it just for that alone though...
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.
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!
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
This blog has a definition of epics in JIRA:
Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Using the above example, an epic might be the entire account management feature and the ability to see previous purchases.
So if (as a product owner) I have a large feature I want delivered that will comprise many smaller tasks and likely span sprints, then an epic is a good choice.
However, I could just as easily create a (using the example from the blog) "Account Management" component, and any task related to that feature have that component assigned.
Similarly I could also just as easily use a label of "Account_Management", and any stories/tickets that are a part of the Account Management feature simply get tagged with that label.
So my question: why/what circumstances would you use an epic? why/what circumstances would you use a component? Why/what circumstances would you use a label? Ie - all three (epics, labels, components) seem to serve very similar purposes (grouping a collection of issues), what's the difference?
With labels and components if you want to select a group of them you need to use issue search. If you are using epics you can use issue search as well, but you also get built-in functionality in JIRA Agile.
In the backlog view of a JIRA Agile board you have an Epic tab. This tab allows you to select the issues associated with individual epics. Plus it has functionality that makes it simple to add new issues to an epic. The final advantage is that the epic name is displayed brightly coloured alongside the issues in the list. This can be very useful when viewing the backlog and getting a feel for what work is coming up next.
You can see more about epics on the Atlassian Working with Epics page.
Components are useful for the technical team as they can span across many epics. A typical component might be 'database' or 'UI'. JIRA offers the option to assign work for a particular component to a particular JIRA user. For example, all issues created with a component of 'database' could be assigned to Jill Smith.
Labels are much more adaptable and they have the advantage of allowing multiple assignments (so more than one label can be associated with an issue). With labels it is very much up to you how you use them.
Epics by definition are short-lived issues when compared to the project as a whole. Components and Labels on the other hand are forever. And, you should stick to use them by their true meanings however tempting it may be otherwise.
Create Epics for features, or as mentioned by #Sateesh, for bigger stories. They should solve their purpose, and once the business need is done for, they should then be closed/done.
Components are not features. They are the technical parts of the system. They can also be used for categorizing your parts or... well, components :P... of your product.
Labels can be anything, as mentioned by #barnaby. Typically, they are keywords, catch-phrases, words people may want a task to relate to, etc. I use it mainly to make issues better searchable from a long-term perspective. There is a JIRA plugin which gives you a JIRA label cloud (for purely fancy purposes, I feel :D) that might interest you, too.
Addition:
Atlasian now have created a new article explaining this from their perspective.
https://www.atlassian.com/agile/delivery-vehicles
My opinion / usage.
Labels and Components are almost straightforward and well answered already.
Components examples
Android client app
Server API
Database
etc.....
Labels examples.
Business logic sectors (ex Orders,Invoices,Users, Products)
Code Quality Improvement
Refactor
Usability
User request/complain
Generally whatever helps categorize things.
But let me give my two cents about Epics because i find this phrase way too generic.
Epics are significantly larger bodies of work
Larger? 10 Sprints? 10 Stories? 20 Stories? or what?
Personally i would classify Epics as Goals or Major Releases.
At a Yearly / Quarter Retrospective your company holds a meeting with all members and stakeholders , and concludes to the following
We need to target more platforms (epic = Platform Expanding)
Our support personnel needs more tools to handle issues. (Enrich Support tools)
The software is too hard to use! ( Redesign UI UX)
This would mean 3 epics with set of stories to cover each of those generic requirements
Epics are bigger stories which require more than one sprint to complete. One Epic may involve several user stories. Each user story may belong to one or more Component. Say, you have an epic airline availability search. This may have multiple User stories like OW search, RT search etc., Some or all of them may involve components like cache, travel policy & booking engine.
Labels are just for convenience. It may not have physical significance.
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.