Are greenhopper projects supposed to be integrated with Jira defect tracking projects - or separate?

Have a basic structural question about the PROJECT in Greenhopper/Jira. Is it one 'project' for agile planning and a separate 'project' for logging and tracking the issues for the devleopment projects?

We have used Jira for years to log and track issues with projects.

We are testing Greenhopper now - but frankly find it difficult to determine where the Scrum modules end and the Dev/QA begin. Greenhopper Documentation and forums seem to imply code is developed and then ready to deploy. Never any defects in the code.

Does this mean that the sprint is planned and coded in a Greenhopper 'project' and the QA is logged and tracked in a separate JIRA 'project". Meaning when code is ready for QA - the QA team logs defects in this separate project? And only those defects that mist be fixed get migrated (moved) to the appropriate sprint in the Greenhopper project?

Or is it all one project? If a single project - is it best to have BUGS indicate issues that were found in production and included in the sprint (a regression defect)? Then the sprint is comprised of prod bug fixes needed and new stories.

Then reserve DEFECTS for issues found in testing THIS iteration? And the iteration is not ready until those defects are either fixed or targeted for future iteration?

Please advise how this was intended. And how it is used in practice. This distinction impacts how we set this up.

2 answers

You ask a great question but I don't believe it's related to greenhopper.

What I've found in practise is the development team and business need to decide if defects are tracked in sprints or not. (or at do bugs count towards velocity or not)

I've heard answers on both sides but generally when I use Greenhopper, yes, it is also used to track bugs.

In fact, really, I don't use much of JIRA except greenhopper, in that 99% of my view when I'm looking at JIRA, is greenhopper (task or rapid board)

0 votes

Is it fair to say your question could be rephrased to "How do you manage QA in an agile environment?" Am I understanding it correctly - that bugs discovered during the iteration need to be tracked and estimated as well?

At Atlassian, we've got a bit of an interesting situation, since we also dogfood JIRA during its release. We expose JIRA for all bugs and features over at, but then on top of that we track internal regressions on our dogfooding server. Therefore, not only do we use a separate project, we use an entire separate server. The idea is that server is running the current build so we're dogfooding as we go.

Yes I am trying to find out if most organizations using jira/greenhopper find it useful to log and track, within each sprint, the bugs discovered in the iteration.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

628 views 0 7
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you