In our company we have recently started using Jira with Greenhopper, however it feels like the system configuration is not correct.
In Greenhopper, we do have a list of sprints and combine stories/tasks inside those. However, we do not use versions and rely on sprints only. This brings some problems: when we edit a task, its "Fix Versions" and "Affects Versions" fields show "None" and don't allow to pick a Greenhopper sprint. And you can only move a story from one sprint to another by doing drag-n-drop in the Agile board in Greenhopper.
From the other side, if we create a version in Jira, we then are able to attach a story to it, however this version would not appear in the Greenhopper Agile screen.
So, what is relation between Greenhopper sprints and Jira version management? Is it possible to have versions and link Greenhopper sprints to them, so that I can see sprints in Agile board, but also can assign a task to specific sprint from the edit screen?
And we use Greenhopper v6.1 and Jira v.5.1.4
There is no tie between a sprint an the version.
Some workarounds include putting a transition (and the screen) which asks user for a version. Or you can also do a bulk edit at the end of the sprint and set the version then.
I have to admit that I was annoyed when they stopped using versions, and instead went with this disconnected sprint model. However, after using it now for a while, I see it's merits. It really shines when your team works on multiple projects with separate release schedules.
What my team is doing is tracking our releases for each project by assigning stories to a release based version for each project. We acutally use the classic boards sometimes to manage the overall release. We assign user stories up front as a target for what we want to include in the release. The agile dashboard comes in handy to monitor the burndown of each release.
The rapid board/sprint then is a conglomerate of all the userstories across the projects that our team will work on this sprint. We've just started this process (with multiple projects) so I'm not 100% how it will work out, but it looks good in theory. However, there are some features that would really help. I'll list some of the ones here.
1. Ability to filter plan view on the fly using a JQL in the search field. Yes, I know you can make quick filters, but they soon get out of hand when you have alot.
2. Ability to automatically filter plan view by assignee. We have a large team and making quick filters for each team memember is annoying. We load our sprints per individual capacity. I know that's not truly agile, but it works for us. Also, using quick filters is not so quick when they are mutually exclusive and you need to "unclick" one before or after clicking another one.
3. One idea I had was to allow for multiple swimlane configs for work mode mode at least. So as a project admin, I can set up a rapid board with a swimlane config to assignees, or for priorites, or whatever. Yes, I know I can make multiple rapid boards. The problem is then I have to recreate any quick filters I make on each one. It would be better to have named swimlane configs with a dropdown on the rapid board.
4. My admins haven't yet updated our server to the latest and greatest Greenhopper with the Epic handling, but I tried it on the GH site and it seems very cool. I would love for them to somehow extend that idea to work off of components and assignees and even projects. I think if we eventually had that, we would have everything we need.
Anyway, that's my too cents.
Same thing for me, in the begining I was not sure of the value of separating Version and Sprint but after using it for several Sprint and Release, I think it s how it should be.
It's especially true if you are working in Scrum. This setup support many important aspects of the process. For example, Scrum says the team deliver a set of functionality at the end of every Sprint BUT it s up to the Product Owner to decide wether or not it has to be deploy to the end user. Many reasons can support this decision (business strategy, quality, etc..). So with this setup you can track both when a feature has been delivered (to the product owner) and when it has been effectively "released" to the end user.
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events