How do you do project planning with the new boards?

[Brett Ryan]

I can not find out how to get to a "Planning" board in the new green-hopper. I like the old greenhopper planning boards as I can simply drag and drop to release versions.

While the new cards look "prettier" they also take up a lot more screen realestate. In classic I generally only show a one line for each card.

Why are atlassian discontinuing the old boards? I think they were much more functional than the new ones.

[Chris McFadden]

I like the new boards in general but liked some of the reporting in classic mode, especially release burn down charts for either story points or issues. Would be great if the concept of a release was captured in this way in the new boards

[sclowes]

Hi Brett,

We're sorry you feel that way, we're getting great feedback on the new boards being much more functional for most people. In plan mode issues take up just one line.

I'm not sure what you mean by getting to a 'planning' board in GreenHopper, it's been replaced by plan mode on each board. If you'd like to access the Classic Planning Board you can do that by clicking 'Classic...' in the Agile menu.

Thanks,
Shaun

[Brett Ryan]

Hmm, maybe that's the grayed out "Plan" button on mine? How do I access the plan mode?

In task mode in classic I use the compact layout which only takes up about 30px height, is it possible to do this in the new boards too?

[John D Patton]

FYI

Here are the three videos that helped us get started in the new boards - the documentation seams to be based more on the classic still but these videos are on point. If you give them a chance I think you will find they do everything you need them to do. You will need to do a few "modifications" if you want them to retrofit an existing classic workflow - but for us we use the JIRA Simplified Workflow and love the user flexibility.

I have 5 development teams, a service team and 2 Product teams moved over to the Rapid Boards...

In depth look at Rapid Boards:

http://www.youtube.com/watch?v=57xYGGbBemE

Greenhopper 6 Webinar:

http://www.youtube.com/watch?v=2-_qCly1vog

High level overview:

http://www.youtube.com/watch?feature=player_embedded&v=KWiSkH9Tqbo#!

[John Garcia]

It's very important to build a Scrum board rather than a Kanban board. The sample projects can be very instructive as well.

Good luck!

[Brett Ryan]

Oh, so you can't target based on versions anymore? You have to target based on sprints?

What I used to really like about the old boards is you could move epics or large tasks to different target release versions, then break those down into sprints, though we use sprints more-so as mile-stones instead of the usual 1-week work unit sprint.

Am I going to have to relearn Greenhopper? i.e. how do I release versions now? It all seems very foreign to me all of a sudden.

[John Garcia]

Releasing sprints is done in Work mode, using either the control at the upper right on the Board or the gear next to the Sprint name on the newest versions. We've added some really groundbreaking functionality with cross-project sprints, and this required building from the ground up. This has allowed us to improve the Boards in some pretty fundamental ways, including instant refresh, parallel sprint, and future sprint planning. We're pretty convinced that once you become accustomed to it, you'll find the Boards to be a lot more natural and effective way to plan your work.

[Brett Ryan]

Thanks John. I'm happy to try get used to this. I can now see where to complete a sprint, though shouldn't that be the project manager doing that in the plan mode? Also, how does a sprint relate to a version? When all sprints for a version are released, can the version be released? I used to like releasing from the planning board, now you need to do it the old way? aka. Project > Administer Project > Versions

[Michael Brinkman]

I have what is really the same question as Brett, although I'm going to present the use case a little differently...

At the end of the day, our business doesn't care what kind of execution process we use to build, test, and deliver a release. Agile, waterfall, and all their variants are just a means to ship better software faster. They really just want to know the cannonical set of issues that are planned to be or were in fact part of a release. In JIRA the facility for tracking where issues arrived or where they're closed has always been the version system and outside of GreenHopper, that still seems to be the case. So honestly I'm shocked that the answer is "use bulk update to note that all the issues in a sprint were really part of a particular version" in order to answer the truly interesting question of "what went out the door and when."

I do understand that one team's work in a sprint could be for multiple versions and so there's a need to allow versions to be orthogonal to sprints. But there has to be a better way to handle this across both JIRA and GreenHopper than a process which invites human error to enter the results and disregards the rest of JIRAs fixation on versions. Honestly if I could just associate a sprint with a default fix version and make sure that all the tickets that are added to the sprint inherit that fix version unless it's then changed, that would be 90% of what I need and would allow me to handle the cross version work on an exception basis.

Thanks