How do Greenhopper boards interact with each other? Is ranking global or local?

[Ert Dredge]

I want to know what the intended behaviour is when multiple boards pull from overlapping projects. Does the rank of an issue on one board affect the rank of the same issue on a different board? Or is rank local to each board? Are sprints-in-planning visible across boards? How are multiple teams working from the same set of ranked stories supposed to plan around each other?

Judging by the fact that each board can only have one sprint in progress at a time, I gather that the intention is for each team to have a board of their own. That's fine, but in experiments I see that two boards pulling from the same project interact in surprising ways: Pulling a story into a sprint on one board doesn't affect its presence on another board, but if you pull it back out of the sprint-in-planning it does seem to affect its rank on the other board. This makes sense from an implementation view since it appears that when you use the default Scrum board creation it uses Rank as the sorting field and the rank is recorded on the issue itself (not on the board), but then I don't understand the purpose of saying you can only have a single sprint in progress at a time -- if there is a single rank, that implies a single board, and multiple teams need to share that board, non?

I picture boards as a layer on top of projects, each drawing from one or more projects for issues but keeping their own ranking. This would allow me to manage ranks appropriately for my dev groups. But it seems that ranks are actually global or have some other scope that I don't quite understand.

(Using GreenHopper 6.0.1)

References:

https://answers.atlassian.com/questions/139548/sorting-by-rank-from-multiple-projects

https://answers.atlassian.com/questions/129255/scrum-of-scrum-board-principles

https://confluence.atlassian.com/display/GHKB/Difference+between+Global+Rank+and+Rank

https://jira.atlassian.com/browse/GHS-3720

https://confluence.atlassian.com/display/GHKB/Changing+a+Rapid+Board+Rank+field

[sclowes · Accepted solution]

Hi Ert,

Almost everything in GreenHopper is global, in fact the only thing that isn't global is 'Upcoming' sprints in individual boards, they are not shared, but everything else is.

In relation to your questions, "Does the rank of an issue on one board affect the rank of the same issue on a different board? Or is rank local to each board?"

Rank is always global, i.e. each board that has a filter with "order by rank" will share the same ranking because they share the same ranking field. You can add extra rank fields to your system if you need them and order different boards by different rank fields, but that's a pretty uncommon thing,

"Are sprints-in-planning visible across boards? How are multiple teams working from the same set of ranked stories supposed to plan around each other?"

No, upcoming sprints are not visible across boards. The logic behind this was that teams working off the same backlog don't actually claim items as their own until their sprint begins as they might well find they don't have capacity. This is important for some teams because otherwise a team might 'claim' a story in their upcoming sprint but then find they can't include it, if the other team could have taken it this means the most important items in the backlog (as expressed by rank) won't be delivered to the customers in that order.

Obviously teams working together off the same backlog need to do some degree of planning together (if they intend to 'reserve' items in upcoming sprints). One way to achieve this is by labelling items that will definitely only be claimed by one team then using a quick filter.

"Pulling a story into a sprint on one board doesn't affect its presence on another board, but if you pull it back out of the sprint-in-planning it does seem to affect its rank on the other board."

If a story is included in a started sprint then the sprint will appear in work mode on any board whose filter includes that issue. Rank will always be affected by dragging an issue around, regardless of the board its performed on.

"but then I don't understand the purpose of saying you can only have a single sprint in progress at a time -- if there is a single rank, that implies a single board, and multiple teams need to share that board, non?"

As Ahmad noted, you can use a labs feature at present to have multiple sprints active per board. One alternative way to do this is to use different boards per team then apply a 'Label' or component to the issues when you start a sprint such that those issues don't appear on the other team's board any more. There's quite a bit of discussion around this on this other answers post.

Thanks,
Shaun

[Fabian Meier]

Why is the ability to have multiple global rank custom fields and use them on different rapid boards not documented anywhere? This is an awesome feature!

Example:

Whe have maintenance backlogs, product backlogs and team backlogs. The ranking is done in meetings where stakeholders of each group compare their backlogs and the ranking they gave several certain issues.

[Andrew Fisher]

I just discovered this post, and verified (on a test instance) the theory of being able to have multiple rank fields. I had a filter (& scrum board) ordered by the default "Rank" field, and added another "Global Rank" custom field called "RankTest". I was able to create a 2nd filter and scrum board ordered by RankTest, and confirmed that the ranking worked independently between the 2 boards.

Given that enabling boards to use separate rankings requires system admin changes (i.e. adding more custom fields, re-indexing the db) and carefully managing the names of any new fields (e.g. which boards are using which custom rank fields), does anyone have any best practices / suggestions on trying to leverage multiple rank fields across the system?

[Deleted user]

We do this extensively across our business (using JIRA classic at the moment - we didn't think it was possible with the new boards because Atlassian closed the ticket I raised rather than telling me what you just have).

It is annoying to administer because we have a custom field per stakeholder group so that they can rank their items independently. We have Sales, Support, Development, Product Manager, Operations etc. (I think 8 in total).

We just don't put the fields on any screens.

It's clunky but effective for us - because a rank forces our stakeholders to choose rather than put everything at high priority!

[RPandyaram]

Hi @Shaun Clowes [Atlassian] Could you please share what are the impacts if we go for custom ranking fields for different agile boards under same project ? I am referring to your point "You can add extra rank fields to your system if you need them and order different boards by different rank fields, but that's a pretty uncommon thing"

[Fabian Meier]

Quick update: We have successfully used custom ranking fields for 2+ years now. We have ranking for features / business value, maintenance backlogs, within our support organization, etc. You can think of a ranking field as a linked list that is represented in numbers which are used to rank the issues. You can create as many as you want and an issue can be in multiple of these ranking lists. All you do in your board is sort by your custom ranking field and greenhopper / jira agile will automatically adjust this rank field instead of the global one. We use this e.g. to rank the same defect within development but also in a maintenance queue. The global rank developers use to rank it in their backlog does not have to equal the rank the clients give it together with the maintenance owner.

[RPandyaram]

@Fabian Meier Thank you very much for your kindest response :) It helps a lot.

[Faisal]

Hi Ert,

As far as I know, GreenHopper ranking are global rather than board specific. As an example here, let's say there are 2 boards that is using the same Ranking field, and issues in the boards are ranked appropriately. With this setup, actually the issue ranking of the 2 board is defined by a single ranking chain in the database. If you would like to see the data directly from the database, the table involved will be AO_60DB71_ISSUERANKING.

However, I believe that it should not be possible for you to have a single issue to appear in multiple GreenHopper board.

And actually, it is now possible for you to start multiple Sprint at a time (parallel Sprint) on a single board in the latest GreenHopper version. The Parallel Sprint was implemented in GreenHopper 6.0.3 and above:
https://confluence.atlassian.com/display/GH/GreenHopper+6.0.3+Release+Notes#GreenHopper6.0.3ReleaseNotes-Parallelsprints

I hope that this will help. :)

[Gonchik Tsymzhitov]

Hi @Steven F Behnke 

Thanks for that info, 

BTW, is it really helpfuyl to have a lot of Rank custom fields? 

[Steven F Behnke]

According to these issues, the Greenhopper team added this functionality in Agile 5.8. It appears that the API is designed to update what ever ranking field the board is using to rank with. Which is awesome.

https://jira.atlassian.com/issues?jql=key = GHS-3723 OR parent = GHS-3723 ORDER BY issuetype