Jira has epic typed tickets and normal issues, and subtasks. Normal issues can be assigned to epics and ordered inside it. It is a visual thing only because it does not effect the dependency settings (blocks, blocked by, relates, etc...). In the view screen of an epic ticket we have the "Issues" section where we have
Rank to top
Rank to bottom
features for each item which is fine. But I really miss the "Rank one up" and "Rank one down" features. Using the Rank to top / bottom feature to move an issue by one in the list is a pain. I can also make the "Rank" field visible on the "Edit" view and see the associated number and edit it, but it is still very inconvenient.
Do you know any plugins, easier practices for it?
(The "Structure - The issue organizer" seems OK, but is to expensive for our setup (10-25 users, $600) just to achieve this goal.)
The Rank functionality (renamed Send To Top in a recent release) is implemented as a WebWork action (e.g. RankTop.jspa which then calls the RankAction class). To have your own action you'd need a plugin that implements a new action and uses the existing RankServiceImpl class to move an issue up or down one rank.
I don't know of any existing plugins to do this but I agree it's annoying trying to move an issue around in a backlog of more than about 40 issues
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!
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 two project setup, both using the Scrum template. In one of them the sprint backlog board shows swim lanes/columns as I would expect:
To Do
In Progress
Done
In my other project (the one that matters, of course), it looks as if the columns from the Backlog Items have been merged with those of the Sprint Backlog items and displays with all of these columns:
To Do
New
Approved
In Progress
Committed
Done
The extra columns appear to be read-only in the board view and do nothing but make the board cumbersome to use. Have I changed a setting somewhere that affects this?
You probably have one team (or project) configured to have bugs on the backlog as requirements, and another team/project configured to have bugs on the backlog as tasks.
Bugs have a different set of states, so if you treat bugs as tasks, the board will show two sets of states: One for bugs, one for tasks.
This can be configured by going to your team's settings (click on the "gear" icon on the top right in VSO, then Overview tab, then choosing the team and looking at the settings).
Daniel's answer pointed me in the right direction, but it still wasn't clear exactly what steps to go through to fix the issue. Here are step-by-step instructions on how to set the number of columns on your sprint board based on how your team works with bugs.
Note that this is a modification from my original answer. The way to fix this has become dramatically easier after the latest update to VSO.
Click the gear to edit settings on the sprint board:
Click Working with bugs under the general heading in the left column.
The option you select here determines how many columns appear on your sprint board.
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.
We're evaluating the 45 demo of fogbugz. Thus far I like it, but there are some obvious things I'm missing.
What boggles me the most is how I can easely alter fields in the list view. I would like to open the detail screen as little as possible. It seems to be possible with the estimation column, why isn't it possible with all the other fields (like project, priority, status etc.?).
What you are asking for can not be done in FogBugz 6. You have to open up the case in order to edit most of the fields. Why they made exceptions for time estimates, I don't know.
The rationale here was as a feature to accompany quick case entry. (That's the "Add Case" link at the bottom of each group or at the bottom of the grid.)
The thinking was that it'd be neat to be able to add cases quickly and then burn through the list, estimating them quickly. We didn't really expand our thinking to include moving cases around or changing things like releases/milestones, etc.
This is something we'd like to offer in the future for many more fields, and one of those weird situations where adding a small, specific feature can sometimes make the fact that the larger, general implementation of that feature isn't there yet.
FogBugz 6 isn't big on customisation. You can edit the categories and statuses in the database tables directly (though you need to edit the "internal" project and click OK for the cache to be refreshed.
FogBugz 7 is coming out this year hopefully, and may well address many of these issues.