Questions: Best Practices GreenHopper usage

Question

We have had several issues on Greenhopper usage  with fields & burndown charts, managed boards,sprints etc. Is there a specific best practice guide?

Here are some issues we needed addressed:

1. We have a single Jira shared across Development & QA. Both groups want to use estimated time. Are there custom fields we can add on the same JIRA that shows QA time & DEV time? Or do we make them use Story points and there own scale?

2. We seem to be limited  by active sprints on managed boards. We have to break down each board by product features which could mean hundreds of boards due to backlog. Is there a way to break this down easily?  We aso group by big features, small features, bugs, minor, major etc.

3. We would have to answers questions like:  "How are we doing on Release 8?".  There would be no simple way to breakdown all the components separated bya QA, DEV, TECH etc in an easy view.

So we would probably need a best practice guide for SDLC  process. Any sample boards, sprints, views.  I am sure this would include  VP views, Tech Views, QA views

YC Lian · Accepted Answer

Hi @KP11,

I'll answer not based on how GH is usually used but how a Scrum team usually does things.

We have a single Jira shared across Development & QA. Both groups want to use estimated time.

Any reasons why QA is not part of the development? In Scrum, the definition of Ready and Done should include the readiness and completeness of a Story not just from the POV of writing code but testing as well as other necessary activities such as documentation. A Story is estimated, worked on and relesable within a single Sprint based on these.

I will recommend both team to work together and share the same point-scale.

We seem to be limited by active sprints on managed boards. We have to break down each board by product features which could mean hundreds of boards due to backlog. Is there a way to break this down easily?

A development team usually works just on 1 active Sprint. How big is your team? You should consider splitting them into multiple Scrum teams by having ~7 people per team. That will also mean: multiple product backlogs but one PB per team.

GH starts to support Parallel Sprints quite a while ago. You can read about it from this answer.

There would be no simple way to breakdown all the components separated bya QA, DEV, TECH etc in an easy view.

AFAIK about GH, you can have separate boards to provide views of the state based on filters (but manage on only one board).

So we would probably need a best practice guide for SDLC process

You probably need to do it the Scrum way. :)  It's a Scrum board.