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.
Related
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...
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.
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 have been using Rally for Project Management in my previous organization, and now I have to use Jira Agile for the same job in the new organization. I am having hard time understanding the way JIRA Agile works, and could not get a hang of the tool after a week of struggle. I am sorting expert help for what I would like to achieve. I have been using JIRA for many years as a bug logging tool but not as project management software.
All I want is to create an Epics and Stories, schedule it into a particular release or sprint. On Rally this is straight forward. Few images attached here.
I could also see the burn-down once I do the above setup, and the developers/qa start burning down or burning up the hours.
I could not achieve the same on JIRA. It asks me to create a scrum board, but I don't have a clue on how to add the child tasks to a story without creating a new child task (which I don't prefer as the tasks were already created and few started progressing).
The scrum board is also not the way it is on Rally, as it does not list the stories but directly shows the tasks which I am unable to correlate with the story. Can any one point me to a proper tutorial or assist me based on your experience in JIRA? Thank you in advance.
I can recommend two things that might make it a bit more easier for you to transition from how you structured your projects before: the Jira plugin "Structure" and using epics, stories and sub-tasks in a defined and controlled manner.
About the plugin: Structure allows you to define a structure, a container that may even span multiple projects, and lets you put issues in. Secondly, and more important, it allows to create any number of sub-task levels. You can use the structure view to show and hide sub-levels, or if you use the agile boards you can just apply a quick filter to the board.
The same goes for using epics, stories and sub-tasks, just make sure everyone able to enter issues follows the same criteria and then add some filters.
Hope this helps a bit
You may want to look at https://confluence.atlassian.com/display/AGILE/JIRA+Agile+101 - it should cover most of the basics to get you going.
My team is using greenhopper, but I have tasks in different projects because I'm on several teams. Is there any way that I can see my all of my tasks in one place in greenhopper? In Jira I set up an issue filter that showed everything assigned to me.
Support [for] multiple projects within GreenHopper has been the highest voted feature request in GreenHopper's history and is meanwhile available as of version 5.8, see Support for multiple JIRA projects on the Rapid Board:
Teams can now view and transition issues from multiple JIRA projects
on the one board, the Rapid Board. On the Rapid Board we have removed
the old concepts of Project and Context and introduced a Rapid View.
The Rapid View is based upon JQL allowing teams to select only those
issues that matter to them.
With the Rapid Board, the GreenHopper team has crafted a very powerful new architecture based on the JIRA Query Language (JQL), which basically aims to make the board fully customizable by building rows, columns and quick filters on top of a respective JQL query.
This is part of a long term product evolution, see The Future of GreenHopper for details:
In GreenHopper 6.0 we plan to push the existing boards (Planning,
Task, Chart and Released Boards) to a Classic Mode and drop the
"Rapid" title. The existing functionality on the Planning, Task, Chart
and Released Boards will continue to be available for a number of
releases until it becomes clear that the majority of customers have
switched over.
Please note that the respective functionality of the Rapid Board is evolving quickly accordingly, and features are usually introduced via GreenHopper Labs first; in addition you'll need a relatively current JIRA installation, e.g. at the moment JIRA 4.4.3 is Required.