JIra + Greenhopper - how to do Agile correctly

Question

I am new to the Agile flow in JIRA + Greenhopper. I am trying to understand what is the correct/better way to work Agile in JIRA + GH. I've read on the net for some information - so far, I understand we have Stories and Epics (which are LARGE stories). I wanted to know what is the flow of creating the tasks:

1. First, we open a story/Epic and define it in a non-technical text.
2. We can create subtasks to the story ( I have technical-subtasks only now).
3. after opening the story - For development, new tickets (bug/new feature/task etc) are created and are linked using the ISSUE LINKING to the story.

Is this the correct flow? My questions are:

1. I dont understand why in (2) we should open subtasks for technical issues if I open development tickets seperately and link them together - so what is the purpose of the sub-tasks in story?
2. Is there a better/easy way to create the dev tickets directly from GH? or must I open them seperately and link them to the story parent issue?

Thank you very much for the quick response.

Answer 1

How we've been using it is as follows:

1. We create a story to define a feature request (a non-technical task in your verbage)

When we plan an iteration, we will prioritize the stories that we want to accomplish. For each story, the team will create tasks (sub-tasks) on how to build the story. These tasks are specific things to be done: Create database table, change controller code, QA the feature, update Public Documentation, etc; along with the person that will be performing the task and their estimate on time.

As the iteration progresses, each team member logs their work done on each task as well as refines their estimate on the task as they have more information. When the task is complete, it is closed. When all the tasks are complete, the story is ready for deployment.

Also, when you are creating sub-tasks, if you choose the add sub-tasks from the card view under the gear wheel, it will bring up a card to enter the items on the task (similar to the card creation), where you can continue to create subtask cards until done. In our opinion, a very quick, easy way to enter tasks.

Hopefully this helps. Let me know if you have any questions or want more details on anything else.

Answer 2

I think it is important to note that the flow differs from team to team.

For instance, some teams have a product owner who starts with the Epic and then breaks that down into Stories, adding acceptance criteria / conditions of success as they go. Often in this scenario the team will come together in a planning session and decompose those Stories into Sub-Tasks.

Some teams give a story point estimate (generally fibonacci) to the Stories, others allocate an hour estimate to the Sub-Tasks. When allocating an hour estimate teams often update the Remaining Estimate as they progress. This gives a good indication on the hour burndown chart what the sprint progress is.

I have also seen teams where the product owner creates a lot of Stories and aggregates them manually into Epics at a later time. If I had a preferred method it would be the first approach for ease, but there will invariably be Stories that are missed/forgotten and are added during a planning session.

The Epics generally scheduled into anything other than a release backlog as they often span multiple sprint backlogs. Both sprints and releases are handled as Fix Versions in JIRA, nesting of parent/child backlogs helps provide visualisation as to what is planned.

This is for scrum. If you are interested in kanban then I can share what I have seen teams do in that scenario, just say the word.

Cheers, Nicholas Muldoon