I am used to Rally, and I am evaluating if it's possible to use JIRA+Greenhopper to do Kanban based user story management. So far, I've discovered that with a lot of work, I can get around JIRA's naive assumpion that a user story can be treated like an issue (which is total bullshit, a user story is NOT an issue, it's a requirement. Issues have resolutions, user stories get released, the two are just not the same) It looks like I can disable most of the out of the box features designed for issue tracking, and use the system instead to create real user stories, with the proper status changes and fields and workflow to be managed in a Kanban board.
This is turning out to be very complicated. It's taking a lot of work to configure JIRA to provide real user story tracking functionality. Rally works out of the box to treat user stories as user stories as opposed to issues. I am wondering if anyone has tried this? I am affraid that after all the work I do, I will keep running into JIRA forcing me to treat a user story as if it was an issue.
we are using jira for backlog management and story creation. It works fine for us, because we splitted the planing from the grooming. That's a common best practice. To be more concret...
1) ... we ignore the issue view for all stories by filtering. So we keep focus for bug tracking there.
2) ... we use greenhopper for estimating, planing and ordering (prio.) stories. This is very usefull because you can easily assign the stories to releases / iterations. We don't care "how" greenhopper is doing this in behind - and I guess that some issue fields are missused regarding the issues context.
3) ... we use the Structure plugin for creating, splitting and managing the stories (grooming). So a story which splits becomes an epic and it's child are epics or stories. We do even see which story is asigned to which release / interation in this view - even if a wrong field is used, it's just a cosmetic problem in my eyes.
We a little customization in the view's (like filtering epics in greenhopper, ...) it becomes a very good backlog tool.
Yes the structure plugin is totally different from Greenhopper - GH adds a lot of reporting and Agile functionality over the top of "normal Jira". The structure plugin allows you to represent complex relationships between Jira issues over and above the simple "project/issue/sub-task" that comes with "normal jira". (that's an oversimplification, but I'm just trying to say "yes, very different")
We don't use iterations/SCRUM, we run on JIT continuous flow, so we truly need to be able to manage a kanban status on a user story. So there isn't heavy up front planning going on in the spirit of JIT. So far, I have seen no way but to create a separate project and completely customizing it to do user story management to mimic Rally functionality.
I am interested in the structure plugin, is that different from Greenhopper?
Hi awesome community! In this article, I would like to describe the one of the toolset (service) for the analyze some problems on different Java-based instances, of course, as Atlassian admini...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs