nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Greenhopper Planningboard : Not independant of VERSION field

Nadeem Taj

Greenhopper Planning / Task board

As discussed here: http://forums.atlassian.com/thread.jspa?messageID=257335789

In one sprint, we have multiple teams working to deliver functionality in multiple releases.

We seem to be forced to plan tasks / stories for only ONE release.

Is there any plan to accommodate teams like us to be able to use the Planning Board.

Surely, all we would need is an [ALL] entry or select several release in the final drop down menu?

Please do NOT respond by saying "It works like that because it follows agile methodologies. What you're describing breaks the rules."

Accepted answers

All comments

Mark Stringer

This is a big constraint, that I'm guessing stops a lot of people using Greenhopper. I don't think it's a good idea for a ALM tool to enforce a particular release strategy.

Chris Allmark

It works like that because it follows agile methodologies. What you're describing breaks the rules.

There is nothing in Greenhopper that forces you to work this way. Maybe you should consider not associating your sprints with your releases at all (i.e. not using version nesting) - keep sprint versions and release versions separate. Then as an end-of-sprint process you would manually move truly "Done" work into the release version and punt your "Undone" work into the next sprint version. The downside of this is that it requires much more manual effort and will need tight management of each story.

Nadeem Taj

This is not an answer Allmark! Its great in theory but stinks of fish in practice having 'actually' tried it for some projects...and yes, we are finaly branching for projects.

This method clogs up the entire process, is difficult to manage and generally confuses everyone. It also takes away vital functionality that is offered by Jira, along with the built in "instant" dashboard for each release. Snapshot statistics used everyday to assess how the releases are going needs to be hand crafted.

So I repeat, and I'm quoting "YOU" when you were working with us only recently:

"Surely, all we need is an [ALL] entry or the ability to select several releases in the final drop down menu?"

Its that simple!

Nadeem Taj

This is not an answer Allmark! Its great in theory but stinks of fish in practice having 'actually' tried it for some projects...and yes, we are finally branching for projects.

So I repeat the question to our friends at Greenhopper, and I'm quoting "YOU" when you were working with us only recently:

"Surely, all we need is an [ALL] entry or the ability to select several releases in the 'Versions' down menu?"

Its that simple!

Greenhopper needs to work with Jira not against it.

And it needs to be for Project Mgrs and Programme Mgrs too... not just Iteration Managers / Scrum Masters

Chris Allmark

Thanks for your professionalism "Taj" - I was only trying to help you (and God knows you need it).

Perhaps if more members of your company had taken the time to get involved and looked properly at the capabilities of Greenhopper before having it implemented, rather than leaving it to a single individual (who left you only recently then you would have been aware of the limitations of the product and it's suitability within your (ahem) "organisation".

Maybe using a bug tracker as a project management tool for a large scale agile development teams isn't such a good idea...

Nadeem Taj

Wow Chris.

Er... I think perhaps you're taking this question to the Greenhopper guys a little too personally. This is not a criticism on you or of the way you work.

Cheers for the (ahem) advice. Always a pleasure discussing software developement with you.

Chris Allmark

My previous answer (which you voted down) still stands. There are a number of ways to cut it with Jira/Greenhooper - using multiple projects rather than one über project, using versions, using components, using labels or using custom fields. Yes, Greenhopper requires that you use versions. So what? You have to box the work up somehow and version seems a natural way to do it. I don't see why thats such a problem for you as you could continue to do it the way you always have done with release versions and custom "planned in" sprint fields. It'll work, but you'll lose many of the planning benefits that Greenhopper can give you. I'm adamant that Greenhopper can work for you - but only if you are prepared to review and modify your current way of working. As with any ALM tool you have to match the product to the organisation and vice versa. You will never find a product which works the way you do "out of the box" so compromises have to be made I'm afraid. Good luck. Over & out.

Rishi Shah2

I worked with JIRA at the same "organisation" and found it to be pretty frustrating as a management tool - so agree that we shouldn't have adopted it for managing agile projects, at the outset, without some upfront analysis - but hey we were "agile" so this wasn't allowed!

Now, having just come back for a few months - guess what I am doing ?!

"Fixing" weird and wonderful workflows, multiple versions and other greenhopper associated "enhancements" all brought about so we can have an inaccurate and out of sync planning board to look at in JIRA.

I understand that greenhopper was developed for use with JIRA, as a way to incorporate the tool with common agile methodologies, but it's certainly not that well thought out, and as everyone above has mentioned, requires too much massaging, just so items are updated correctly and reportable - surely the purpose of even the simplest bug tool (thinking of bugzilla here) is to take away this, the most tedious part about managing and tracking software development progress.

To me, a tool like JIRA is only as good as the integrity and accuracy of the information that it contains, adding greenhopper and "compromising" to it's needs has actually compromised these objectives!

PS - It's still better than using MS Office

Renjith Pillai

I am not sure whether I understood your question correctly. We do manage multi product development with a single project in Jira and also have Release burn down separately for each product. Teams pick up items from the single backlog which is a mix of items from different projects.

Sprints are marked separately and not as child of any major release. But every item will have the Fix Version including the product release as well as the sprint name. In order to simplify the usage, what we do is the following.

1. Set the affects version to the Product Release

2. Using the planning board drag and drop items to the sprints in which it is done

3. Have a regular scheduled task which uses SOAP interface and keeps the affects version (the product release) also marked in the Fix Version.