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; } } }

When will the Rapid Board graduate from Labs?

Nicholas Muldoon

Hello,

Yesterday I posted a video of the Rapid Board. This video represents the work of the GreenHopper team over the past few months. As the Rapid Board is still in Labs today I wanted to take this opportunity to share the plan for the next 12 months and invite you to provide feedback on that plan.

Caveat: this is a plan, it is subject to change. Customer uptake of and feedback on the Rapid Board will inform the decisions we make. Please do not provide feedback on the Rapid Board here, please use the "Got Rapid Board Feedback?" link in your JIRA instance instead.

Background

The Rapid Board is a fresh start for GreenHopper. We are building it to take advantage of the latest in web technology and provide you, the customer, with an awesome experience for planning, tracking and reporting on the progress of your agile projects and teams.

One thing is absolutely clear, your agile project does not necessarily map to a single JIRA Project. For that reason we are addressing the most common feature request - GHS-1800, support for more than one JIRA project in GreenHopper. Not being folks to sit still we are taking this opportunity to introduce a new user experience with less page reloads and more useful URLs. Users will be able to share a URL for the displayed page, GHS-990.

The Rapid Board removes the complexity of the existing user interface (projects, contexts, boards, filters, versions, etc) while retaining the flexibility of GreenHopper. In fact, with the Rapid Board GreenHopper is now a whole lot more flexible due to our use of JQL.

One major part of that flexibility is returning the Fix Version field back to its intended use-case, showing which versions a bug or story can be found in. This means decoupling Sprints from the Fix Version field, GHS-945.

We also have a new ranking field, Global Rank, which provides better performance than the current solution. While we have no intention of backporting this to the Planning or Task Boards we know that it will provide a much more performant experience for our larger customers moving forward. For the first time you will be able to rank issues across JIRA Projects.

With the introduction of the Global Rank JIRA and GreenHopper will no longer need to reindex all of the issues in each JIRA Project every evening, GHS-2727. We will provide a migration action for project administrators so that they can switch from an existing Rank field to the Global Rank without losing their ranked order.

There is plenty more coming as well. A few other highlights:

Multiple swimlanes, based on JQL
Quick Filters are now configurable, based on JQL
Control Chart to show the cycle time

The Plan

The Rapid Board will graduate from Labs for kanban teams around October. It will coexist with the existing boards and be the recommended option for evaluating and new customers who are kanban teams (those teams not using sprints). The team will then turn its attention to implementing functionality on the Rapid Board for scrum teams. This will be a Labs feature, "Scrum for Rapid Board" that is opt-in like the Rapid Board today.

We will pursue the same approach as we are with the Rapid Board today, we will seek feedback from early adopters as we develop the functionality prior to "Scrum for Rapid Board" graduating from Labs. When "Scrum for Rapid Board" graduates it will become the "Agile" tab for all evaluators and new customers and it will lose the "Rapid" title. The existing functionality (Planning, Task, Chart, Released) will move to a Classic Mode and be available for a number of releases as existing customers switch over.

I want to ensure that our larger customers who have thousands of users have as much headroom as possible for the switch. As such the Classic Mode will be available through to the first release of GreenHopper against JIRA 5.1 at which point the Classic Mode will be removed. Tentative timing for this is April 2012.

Some questions for our customers:

What is your immediate reaction to the plan outlined above?
How will you migrate your company?
What am I not considering in the plan?
What would make your migration successful?

Thank you for joining us on this journey, all of us on the GreenHopper team are committed to making the transition a smooth and enjoyable one.

Regards,

Nicholas Muldoon

Accepted answers

All comments

Colin Goudie

Awesome work Nic! It's is looking great and I think it will remove the need for setting up squillions of dashboards!

Nancy Belser

When you say you won't need to reindex all issues, how does that affect issues that no longer should be ranked because they have been released? Will those ranks still be optimized via the nightly rank optimization process?

Nicholas Muldoon

Hi Nancy,

Once we migrate to the Global Rank there will no longer be a nightly rank optimisation process. The released issues will still have a rank, although you won't see those issues as they will not form part of your query. For instance, you may have fixVersion in UnreleasedVersions() as part of your query.

Thanks Nancy.

Regards,
Nicholas Muldoon

Nancy Belser

I don't like the idea of not backporting the global rank to the planning board. As I mentioned in another question/answer, the planning board works better than the rapid board for one of the major ways (right now - only) we are using greenhopper. So if we want to continue using the planning board, we will be stuck with the old rank field, which does not provide change history and may declared obsolete at a later date. If other parts of our organization use the rapid board, they will use the global ranking field. Now we have 2 different ranking fields that function differently. Plus, the issues from the project that uses the planning board version of the rank will still be "globally ranked" in the background, even though they are not going to be ranked against the issues of other projects. I am not comfortable with this approach. Please consider that not everyone uses the tool in the way you envision. The rapid board confines users to a certain way of looking at their issues, while those of us who are primarily concerned with ranking in one big list (for the purposes of feature request mgmt), regardless of status, are left with a less than ideal user interface.

I am all for the idea of ranking across projects and I do like the rapid board for agile development, but I don't want to lose the functionality that we rely upon. I think the planning board should be migrated to use the global rank and rely upon filters to winnow down its contents.

Nancy Belser

We need the planning board to stick around. From our standpoint, it would be a good idea to migrate the planning board to the global rank field or migrate the planning board functionality to the rapid board. We need the ability to view and rank a list of issues, regardless of status. The status categories in the rapid board do not work for the particular way we are using greenhopper. I can certainly see the value of the rapid board, but unless I am missing something, it is forcing users to conform to only one way of looking at their issues.

Paul Davis

This sounds great!

What's the current thinking on how Sprints and teams will be managed within this new framework? Are you thinking of adding a way to do resource planning for teams by sprint?

Nancy Belser

angel

@Nancy I believe you can achieve this by creating a rapid board view with only one column (adding all the available statuses). This way you can emulate the planning board. One the other hand there is work-in-progress from the GH team to migrate the classic boards to use the new Global Rank field, not sure though when will this will be available.

angel

Nancy Belser

Aggelos, I think that should work for our purposes. Thanks for the response.

DANIEL W BECK

What is your immediate reaction to the plan outlined above?

Awesome. We have dev teams in 12 jira projects (and growing), and when we work on a feature 80% of the time the feature spans teams. The ability to view jiras across projects is key for us.

How will you migrate your company?

We'll adopt in the next planning cycle. The transition will be smooth as we'll really be dropping the use of side dashboards, spreadsheets, etc. that aim to handle cross project views.

What am I not considering in the plan?

Will be be able to customize the columns like we can with cards? In your video you show the ability to define columns (e.g. status), but I'm wondering how robust this will be and whether we'll have the abiltiy to say have columns for the various cross functional leads with edit abilities (e.g. dev lead, qa lead, etc.) who will be on point for large items? These would be pulled from different fields in Jira vs. values for one field which is what your demo example seemed to show.

What would make your migration successful?

We're still intested in treatined included stories/jiras more like sub-tasks (e.g. GHS-2872). That would help this a great deal as what we really have are items that are cross project, but that form a coherent unit (e.g. a feature). As such the way sub-tasks move with the parent jira is quite valueable as are smaller things like the abiltiy to easily view/collapse the sub-task items.

Nicholas Muldoon

Thanks for the feedback Dan, brilliant!

unknown

Hi Nicholas,

what is the current status of this topic? we are just moving from JIRA 4.2 to 4.4 with 2.000 users and I'm struggling with the decision, when and how we should start to move to the Rapid Board. should we wait until old old GreenHopper goes to "classic" mode and you provide us with migration means?

many thanks and best regards

Rainer Mueck

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software