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

Question

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.

Judy Caesar · Answer

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.

Jeremy Largman · Answer

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 jira.atlassian.com, 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.

Colin Goudie · Answer

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)