Is it really possible to use JIRA to do user stories?

[Axel Kratel]

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.

[Jurica Jurjevic]

Hi,

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.

[Nic Brough -Adaptavist-]

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")

[Axel Kratel]

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?

[sclowes]

Hi Axel, Could you elaborate a bit on the difficulty you're having separating Issues from Stories? The GreenHopper development team regularly uses GreenHopper for our Kanban development. While we tend to use a Kanban task board that includes both bugs and stories ranked by priority it's easy to use a quick filter in the Rapid Board to filter out one or the other. I take your point about Jira 'issues' not being logically related to stories, though in Jira the term really refers to a containers for data that flow through a workflow, so User Stories do fit that criteria, they just flow through a different workflow to a different outcome. Would definitely like to hear more about the bits you find unintuitive or plain backward. Thanks, Shaun