Atlassian GreenHopper and Release Management

Question

We are playing around with Atlassian products and I have prepared an agile sprint using GreenHopper, and little confused with the flow.

Here is how we are doing the current development at my office:

1. Developers completes the issues assigned to them. Mark them as resolved.

2. Once all the issues for the sprint is complete we have a release ticket that provides the release details and we assign it to the INF team to build and deploy in QA. If things are approved in QA its moved to staging, produciton.

3. If any issues found or any of the issues are not resolved we reject the release and assign back to the devs. and devs correct them and prepare another release.

Does anyone have any suggestions on achieving something similar with JIRA+GreenHopper or any better ideas.

Answer 1

It sounds like your process is reasonably straightforward. I'd recommend that you have a go with the new Rapid Boards in GreenHopper 5.10.1. The Rapid Board's have a clear Plan > Work > Report flow to them.

Looking at your specifics I'd recommend the following:

• First create a Rapid Board for the general development. This board would be used for your development team and would have Sprints that include the bug fixes, stories and backlog items. The final column in this board would be 'Done' or 'Ready for QA'
  • At the end of the Sprint the team would simply 'Complete' that Sprint and log a ticket to get the build made and deployed to QA
• I would then recommend moving the same issues as were in the Sprint through the QA process so that each one can be rejected. To do this the QA team can simply have a separate Scrum Rapid Board with the first column 'Ready for QA'. This will allow them to run a separate Sprint that includes issues from the just completed Sprint
  • At the end of this Sprint only stories that are good to go will be in the 'Done' column and the team can decide to deploy just the correct stories or reject the whole release
  • Stories that do not pass QA can be updated back to a status that puts them back on the development team backlog for inclusion in the next Sprint. Alternatively they could be raised separately back with the development team for fixing

Answer 2

We do something pretty similar here, and it all works well within JIRA / Greenhopper:

1. Product owner creates Epics / Themes / User stories in JIRA/Grasshopper

2. Backlog grooming occurs, story thrashed out a bit, and story points entered into user story

3. Sprint planning: Stories are selected for upcoming sprint, and using greenhopper, we create add the stories to the sprint. see below

4. Sprint begins.. Tasks are created in JIRA by developers to track progress, and linked to the user story. Once all tasks for a story are complete, user story is done.

5. We've put scripts in JIRA to have a button for "done" which automatically assigns the story our build team, who merge it into our main baseline (not sure if this applies to you). Once they have put it into a production build, the user story gets assigned to the QA team.

6. QA team tests production build... if it passed, story is closed.

I might add that the QA team might take longer to test the story than the sprint allows - so for purposes of a team's sprint and velocity, the story is taken as done at the point it gets assigned to the build team.

Does that make sense?

JIRA is capable of all of this, it's great - although you might need to do some configuring to setup entries for epics/themes etc.

We use Greenhopper functionality to create and track stories and sprints, but for task progress etc, we use a whiteboard - much more visible, and better for the daily standup.

Hope this helps.. any questions I'll be happy to answer :)