Page edited by Cody Burleson
I feel like Neo in The Matrix now; I am 'the one'. I can see things other people can't see and do things other people can't do. I have special powers. I have GreenHopper
- a plugin for Atlassian JIRA that is rockin' my world. For me, GreenHopper has made JIRA fun all over again.
In my last post, I explained how GreenHopper is good for JIRA, whether you're Agile or not, because it vastly improves the ability to rank issues and visualize priorities in JIRA. Today, on the fourth day of my evaluation, I want to share something else I've discovered that makes the plugin a delight to use.
Defining 'sprints' or phases in a product release
JIRA allows you to define and manage versions in a project and typically, we use these versions to define a software product release. For example, you might set up a project for a software product to have the following versions:
- Release 1.0 ALPHA
- Release 1.0 BETA
- Release 1.0
- Release 1.x
With project versions defined, we can capture all issues whether or not they are relevant to the current phase of a project or release of a product. We can continue to capture new feature requests, for example, even if the scope of our current release is 'locked down'. In this way, we can use JIRA to manage what is in progress while still capturing new feature requests that might apply to a successive release. We can also move issues from one version to another to account for various project dynamics.
Suppose, however, that you want to use JIRA's version management to define Agile 'sprints'. You might define your project versions to look something like the following:
- Release 1.0 Sprint 1
- Release 1.0 Sprint 2
- Release 1.0 Sprint 3
- Release 1.0 Sprint 4
- General Backlog
Alternatively, in a more traditional approach, you might define phases within a given project or product release:
- Release 1.0 Design
- Release 1.0 Construction
- Release 1.0 Implementation
- Release 1.0 Testing
- Release 1.0
- Release 1.x
These strategies can be useful for keeping things organized, but with JIRA alone, the versions are still separate and distinct. We've only related versions of a project to a given release by labeling the versions to imply the relationship. Since there is no mechanism for explicitly defining these relationships, we are left to hope that our team understands the metaphor and flags issues appropriately. With this model, for example, we'd have to ask our users to tag an issue with both a given sprint or phase as well as the product release. Any lack of discipline or mistakes could ultimately degrade the accuracy of our insight and reporting.
The GreenHopper plugin fills this gap by allowing us to explicitly define parent->child relationships between versions. Once these relationships are established, it then flags issues more appropriately and automatically as we work within the GreenHopper interface. For example, if we define a version 'Release 1.0' as the master of 'Sprint 1', then applying issues to the sprint automatically applies them to the release also.
(click to enlarge...)
We can toggle between different planning boards by changing the version filter on the view. That means we can look at a planning board for a given release or we can drill down deeper and see a planning board for a particular sprint or phase within that release. We can reassign issues to different sprints, phases, or releases by simply dragging and dropping them atop the version in the right-hand column.
If you drop an issue atop Sprint 1, it is then automatically flagged as an issue of Release 1 also as shown at left. GreenHopper understands the explicitly defined relationship between the sprint and the release and thus can help in appropriately flagging issues. All in all, this gives us the ability to 'turn the cube' on our project and analyze it from various different perspectives while helping to ensure that those reports are more accurate.
Now, I know that a little feature like this is not going to change your world, but if, like me, you are also trying to improve your overall approach to project management in JIRA, it sure as hell helps. It is just another small example in a rising heap of features that are adding up fast as I evaluate GreenHopper - just another little thing that gives me a feeling I'll be opening my wallet unashamedly the day my trial ends. For me, GreenHopper is a powerful new guide on my journey towards an improved approach.
Neo: What are you trying to tell me? That I can dodge bullets?
Morpheus: No, Neo. I'm trying to tell you that when you're ready, you won't have to.