Daniel,

VersionONE has JIRA integartion that maybe useful to you:
http://community.versionone.com/Downloads/Documentation/Jira.aspx

I believe the integration allows one to use JIRA for bug tracking, and VersionONE for Scrum management.

Cheers,
Anton

Thanks for your replies.

@Antoine, overall, trying to reuse the same issue for everything often leads to way too much mess. It often feels like copying data is annoying and is not ideal. however, it gives a better solution than trying to use the same issue for everything, which makes that issue so complicated, that no one can understand what's going on. For example, if more than one team needs to work on tasks to deliver a particular "feature", using the same issue (or the same project) can get very messy.

If the feature is broken down into multiple tasks, then copying the estimate is not actually accurate, as the estimate also needs to be divided between multiple tasks. I guess, some manual management of JIRA cannot be completely eliminated.

@Daniel, thank you for the information. This is very interesting. I would really appreciate if you could let us know where VersionOne excels over JIRA+GreenHooper.

Cheers,
Anton

Anton,

I know it is possible to track work by iteration in JIRA. Unfortunately it cannot be done well - it cannot be done in such a way that this information is clear and easy to view and enter. It cannot be done in such a way that I can convince our typical project manager that JIRA will work for them.

There are many issue tracking and project management tools out there. JIRA is my favorite not because it has the best features (though it does have lots of good features), but because it's very well designed - in general, it just works well. Unfortunately this is not the case for those of us who need to track by iteration.

I am not making this request on a whim. My company is migrating away from JIRA to VersionOne because of JIRA's weakness in project management (in addition to this, JIRA's lack of hierarchical projects and issues - JRA-846, JRA-4446, and JRA-12241 - was problematic). That was a decision agreed to by myself and my project manager - the very people who had brought JIRA into the company in the first place. (Though let me say that V1 is vastly inferior to JIRA as an issue tracker.) (And yes, we did evaluate using GreenHopper, it was nice but not enough.)

I hope this clarifies my need. Of course I will understand if Atlassian has no interest in this direction, but in that case it might be better to resolve this as "won't fix".

Hi Anton,

thanks for your reply.

I understand, but

• It's a waste of time to create a task for each issue of the iteration, unless there is some sort of bulk linking functionnality.
• You don't have the workload report for the iteration, because the estimate for the linked issues is not copied to the linking one. You could put the estimate only in the linking issues but its not very natural as you should have the estimates availables when you decide to put an issue in the iteration.

Cheers,

Antoine

Hi Antoine,

Yes, you will need to create new issues in the project used to track work for your team. These new issues will represent actual tasks that the team will need to do. You can use Issue Linking to link the tasks back to the bugs or enhancements that these tasks involove.

Cheers,
Anton

Hi,

Anton coul dyou explain to me how you would achieve what Daniel wants by having a separate project? Suppose I want to make an iteration with Issue 1 of project A and issue 2 of project B.

You would create a project called, say, "Iterations management". And create a new version for the iteration. How do you put issue 1 and issue 2 in it? Arent you forced to duplicate the issues?

cheers,

Antoine

Hi Daniel,

I think a lot of functionality that you cover could be achieved in JIRA by having a separate JIRA project for managing tasks for a team, where versions are used to represent iterations. You can disable (hide) the Fix Version Field, and then the road map report will also disappear. For more information on hiding fields see:
http://www.atlassian.com/software/jira/docs/latest/issuefield_configuration.html

We are not planning to add a separate entity to JIRA to represent iterations, as we believe it will have quite a lot of overlap with a version, and would cause a lot of confusion.

JRA-568 is used to track the enhancement of allowing hierarchical representation of versions, which allows to e.g. break up a version into iterations. A lot of users do want to see this. However, from your descritpion this is not what you are after/

In the long run we are hoping to make a lot of functionality available through GreenHopper appear in JIRA.

Cheers,
Anton

Allowing versions to span multiple projects (JRA-2698) does address some of my need. I don't understand how JRA-568 relates to this issue. Maybe GreenHopper answers most of the other concerns (I have only looked briefly at it).

However, this still leaves the problem of there being no differentiation between versions and iterations. As a user, in viewing this information and making reports I may want to keep them separate. I'm pretty sure GreenHopper doesn't solve this issue. A generic way to handle this might be to add a "type" attribute to versions, with values such as "release" and "iteration", and maybe "build" and others. However, I'd rather not have iterations in the "fix for version" list at all. Nor do I want iterations in the roadmap view. I do want to be able to go right to an iteration and see the status, without descending into a project (though I should also be able to select specific projects for that iteration). Maybe GreenHopper does some of that? But I still think it should be in JIRA itself.

Hi Daniel,

If you are doing Scrum development, please have a look at GreenHopper JIRA Plugin:
http://confluence.atlassian.com/display/JIRAEXT/GreenHopper

I think it will be perfect for you.

I believe one of the things that will help is adding support for hierarchical versions, so that it is possible to break up a release into interations. The issue for this is JRA-2698. GreenHopper adds this functionality.

The ability to have version to span multiple projects is tracking by JRA-568. However, I am not sure if this fits into JIRA very well. My advice would be to have a separate JIRA project that is used to track teams work, and then have other JIRA projects, one for each product. You can then use GreenHopper to manage and schedule issues in the team's JIRA project.

I will resolve this issue as a duplicate. Please, vote for the linked issues.

For more information on the way new feature and improvement requests are scheduled, please see:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

I strongly recommend taking a look at GreenHopper. It can help you today!

Also, thank you for locating JRA-7527. I will resolve it as a duplicate of the linked issues.

Cheers,
Anton

This may be similar to the request JRA-7527.