Greenhopper 6.0 - Scrum Board (Fix Versions) - Screen Views - Parallel Sprints

Jon Frampton December 6, 2012

Background: Our company has been using Jira / Greenhopper and one project for over 20 customers who all utilize one form or another of our base software package. With the new upgrade to Greenhopper we have decided to restructure our implementation of Jira / GH. This series of questions will be presented in a way that would be similar to a product backlog.

In true Agile / Scrum Fashion

Product (Question) Backlog

  1. As an administrator of Jira / Greenhopper for multiple Customers (Projects) I need to be able to perform bug fixing / maintenance concurrently within the same start & end dates of the Sprint but not have the time/effort logged within the Jira issue count toward the Velocity / Capacity / Burndown of that Sprint within GH. So that I can release at the end of the Sprint as well as track and report work performed and bill customer if applicable.

    • Condition Of Satisfaction:
      1. Administer a Sprint using a GH Scrum Board with issues that have followed the Agile Planning methodology under the Scrum methodology.
      2. When a customer reports a bug be able to address that bug within Jira so that it is recorded / resolved / reported during the same time frame as the Sprint but not break the Sprint by adding "scope creep".

  2. As an administrator of Jira / Greenhopper for multiple Customers (Projects) I need to be able to configure the creation screen, default view screen, resolved screen for issues by Project then by Project Role / Group type. So that customers have more control over the information that is relevant to their users.

    • Condition Of Satisfaction:

      1. Have a default view for each of the Jira screens but also be able to show specific fields for each project and then by user group and or project role.

  3. As a Scrum Master for multiple, highly motivated, self-organizing teams, working on their own iteration cycles developing disparate software solutions an environment that includes support tools with functionality that encompasses and addresses their desire to have their own unique iteration cycles retrospectives.

    • Condition of Satisfaction:

      1. Finish the feature within the GH Labs called Parallel Sprints so that is meets the User Story above.

Thank You in advance to all of you who have read this far (yes I tend to be long-winded) and for any help you may be able to provide.

Regards,

JF

1 answer

1 accepted

0 votes
Answer accepted
John Burns
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 9, 2012

For number one, there is nothing that prevents you from working on tickets in your backlog without adding them to a sprint.

For number 3, if you have totally separate teams with a separate backlog, multiple rapid boards is probably the preferred way to do it.

If you truly have multiple sprints overlapping on the same backlog, then parellel sprints would be the way to go, and that issue is now in Greenhopper.

There is my 2 cents.

Suggest an answer

Log in or Sign up to answer