We want to implement a solid "road map" for our product development road map. We use Jira (4.4.3) and Greenhopper for our project management and bug tracking but the Jira Roadmap feature simply shows you a list of the versions you have defined.
However, we currently use our "Versions" for each sprint, e.g. "Week 16", "Week 17", etc. which contain all of the tasks/issues for that week's sprint.
We currently use "Components" to keep track of major feature sets and to categorize (e.g. "Integrate with xyz API", "Migrate emails to SendGrid", "Bugs: Code", or "Technical Debt").
The Jira "Roadmap" feature shows the list of versions and the progress towards each. However, we're already using Versions for tracking our weekly sprints, and some of these roadmap features will span many releases/versions/sprints.
How can we keep track of our complete roadmap within Jira? We would really like to see a list of our major initiatives in this roadmap instead of a list of all of our weekly sprints (e.g. "Enable Selenium on CI server", "Extranet MVC3 conversion", "Upgrade production to R2").
Create a roadmap in Jira SoftwareCreate a new Jira Software project or go to an existing project and then navigate to the sidebar and click Roadmap. Note: If you are not seeing your roadmap tab, enable the roadmap in the board setting. 2. Click + create epic on the roadmap to create epics directly on your roadmap.
A Jira workflow has three basic components: statuses, transitions, and resolutions. Best practices for Jira workflows include keeping your workflows simple, not edit live workflows and not confusing “resolution” with “status.”
The mentioned story GHS-945 had been resolved in GreenHopper 5.10 already - meanwhile GreenHopper 6.0 officially delivers all mentioned major improvements regarding Kanban, Scrum and especially custom agile board, planning and process management, plus many others not mentioned or available before. Accordingly the interim term Rapid Board has been dropped as well, see No longer Rapid by name – but still rapid by nature:
In GreenHopper 6.0 the new board is no longer known as the "Rapid Board" — we figure everyone knows by now that it is vastly faster than the Classic boards. The new board has been built from the ground up on newer technology that enables us to provide optimum performance, making the most of your valuable time.
Finally, the GreenHopper team continues to deliver significant improvements in almost biweekly point releases, with the last one addressing one of the few losses caused by the transition from the classic boards: release 6.0.2 features customizable card colors again, even more versatile than the classical variant, insofar you can now base the coloring on issue type, priority, assignee or a custom JQL query even.
Our former workflow including backlog coloring (see What Color is your Backlog?) is now fully migrated to the new GreenHopper, gaining a huge amount of significant new features and improvements on the fly and a respectively more agile and productive team.
The version vs. sprint impedance mismatch in many areas of JIRA and GreenHopper is a well known problem for agile teams using this toolchain. We implemented various attempts to remedy it one way or another (mostly via version hierarchies of sorts, i.e. product versions and sprint versions with parent child relationships), none of which turned out to be really productive.
Accordingly, the relatively dated story Add a separate field to allow tracking sprint and release information independent of one another (GHS-945) captures this topic. While it is unresolved as of today, GreenHopper is currently undergoing a major restructuring to address this (and related) problems, and while not quite finished yet, the respective functionality available today addresses your use case already (eventually), see the Atlassian Status as at February 28, 2012:
Sprint as a separate custom field is now available in GreenHopper 5.9 however it is only used by the Scrum Rapid Board (which can be enabled as a lab feature from the GreenHopper admin screens).
The Rapid Board use of this field frees up fixVersion field for normal use.
The mentioned Rapid Board and the restructuring in general is further detailed in The Future of GreenHopper:
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.
The Rapid Board and related functionality currently improves quickly indeed, i.e. the GreenHopper team iterates fast and implements major improvements in currently monthly to biweekly point releases even.
I'm totally sold on this approach, which basically builds the board on top of the versatile JQL functionality (see Advanced Searching), enabling almost complete freedom to assemble the perfect board for your needs.
On top of that it solved the version vs. sprint impedance mismatch for us, insofar sprints are decoupled entities now and versions can be used as desired again, yielding a useful version and release date based customer facing JIRA Roadmap in turn.
The transition to this new approach is a dedicated effort of course, requiring some planning and time eventually, also there are still some relevant shortcoming concerning the previously available functionality; for example, the currently unresolved story As a user, I would like to configure the cards displayed in the rapid board (GHS-3922) is important for us, because we have been using Philippe Kruchten's innovative approach to backlog coloring (see What Color is your Backlog?) with great success and this is not possible for the Rapid Board yet.
Finally, GreenHopper 5.9 requires JIRA 5.0, which may or may not be a showstopper right now.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With