GreenHopper best practices

[bob ebenze@hotmail.com]

I'm new to using GreenHopper for Agile development. I've been using Jira for years as a standard task/bug tracking software but am starting a new project and would like to use GH. However, I am a little confused how to organize things within GH.

I've created my user stories. I understand how to plan my sprints around my stories. What I do not understand is how/where to associate my tasks to my stories.

For example, one story might be: As a user, pay for my product using Paypal.

Consequently, I have a handful of tasks associated with that story:

- Create DB payment tables

- Research Paypal APIs

- Integrate Paypal processing

- etc ... etc... etc ...

In my backlog, both my stories and my tasks all show up. So I can add everything to the Sprint. But it would be much more effective for me to be able to associate the tasks to the specific story and then just add the story, which would then include all the tasks.

The only way I have found to accomplish this is create all my tasks as subtasks to my stories (or link them) and then filter them when planning my sprints. But this seems like almost a backwards way of doing it.

Is there a better practice for this? Or an easier way to link stories and tasks together (be it improvements, support inquries, bugs, etc)?

Thanks,

Eric

[Ram Muthiah · Accepted solution]

IMHO, bugs should always be top level issues. Bug should not be a sub-task. If I work on a story and that story has a bug, QA either reopens the story or creates a bug and link to closed story.

[PhilB]

I'm not sure I understand what you're struggling with here (but maybe I'm missing something). On the Greenhopper planning board, you should see just the stories in the backlog, not the sub tasks of those stories.

A general process could be:

- Stories, bugs, etc are created in the backlog, groomed, ordered, etc

- Stories are placed in a sprint and sub tasks that define the tasks for completing the story are added to the story

- Estimates are attached to the sub tasks by the team

- Start the sprint

- The Work tab on your board should now show the stories as swim lanes with the sub tasks for each story

If you are creating tasks and stories all at the same level and trying to link them up then I think you're going to have a real challenge trying to manage the sprint board.

Again, maybe I'm missing something here.

[bob ebenze@hotmail.com]

I'm probably the one that is missing something, but having trouble explaining it. I understand the agile setup as follows:

1. an epic is composed of several user stories
2. a story can have several substories
3. a story is composed of tasks/bugs/improvements/documentation/etc required to implement the story

Maybe my understand of point #3 is wrong, but the way I understand it is that a User Story is the business case/high-level problem that needs to be resolved. Similarly, I see tasks/bugs/improvements/etc as the low-level/technical/developer geared issues that need to be implemented.

Consequently, I am looking for the natural way to associate tasks/bugs/improvements/etc to a particular story.

When I do my Sprint planning, I can then choose to assign a particular story to the Sprint, and automatically have all its containing tasks/bugs/improvements/etc automatically become part of the Sprint. Then the developers can implement/resolve one task/bug/improvement at a time. Once all the story's tasks/etc are implemented, the story, by definition, would be completed as well.

Instead, I don't see any natural way to associate these issue types with stories. So instead, in my backlog, I see all my issues along with my stories. When I assign the stories and issues to the Sprint, there is no association between them. Consequently a developer who attempts to implement the story will not necessarily know which issues must be addressed to have that story resolved.

Am I looking at this wrong? Is there another way of accomplishing this? The only way I found would be to link the individual tasks to the story "Is related to...", but then my question becomes what is the purpose of the Story in the first place? Why even bother having the Story as part of the backlog and/or the Sprint at all?

Thanks,

Eric

[Kamlesh Lokeshwaran]

I also faced the same issue. But what I did was created a new Sub-task type and named it "Defect". Disabled the "Bug" Issue type (for me there would not be any stand alone bugs). So now the users can only raise a "Defect" under a Story in my case. Hope this helps.

[Ram Muthiah]

Kevin, this is how we do it.

Developer completes a user story in DEV, resolves it as fixed, push it to INT and let QA know about it. QA tester tests the story in INT.

If the test passes, QA marks it as "INT verified" and the ticket is moved to next tier.

If the test fails, QA tester reopens the ticket and add comments in the ticket about what failed. The ticket goes back to Developer. At this point, developer must fix the bug and the cycle repeats.

If the user story test is passed in all tiers, then it goes to PROD. In some cases, a bug is discovered in PROD. This bug should be a top level ticket. This bug has a link to original user story, if applicable. Developer takes it and fix it.

In our situation, there is no need to create mulitple tickets for multiple bugs in a user story during development. I do not remember seeing 10 bugs in a user story that is in development. I would probably think about assigning that user story to another developer in that case!

[Deleted user]

Hi Ram, in the scenario you described, let's say we are working in a 3-week Sprint, and we have let's say 5 Stories we have pulled into this Sprint. As the Devs complete their work the story is handed over to QA and they start on their Tasks. Let's say QA find 10 Bugs in each Story. This is 50 Bugs logged as top-level Issues. They are automatically created on the Backlog and manually moved into the Sprint. They are moved in because the Story is not 'Done' until it is 'Done'. 'Done' is when QA has passed all tests. Now these 50 Bugs appear in the Sprint as top level Issues, they can be manually linked to their Stories but this is so much admin and so messy, surely having these bugs appear as Sub-tasks under their Story is the best method?

I would really like the ability when a Bug is created, either in Jira or from a 3rd party method such as Zephyr that the user is able to select whether it is created as a top-level Issue or the ability to search for the Story and create it under that Story at a Sub-task level, as both these scenarios are real IMHO.

See also: https://answers.atlassian.com/questions/187663/how-do-i-create-a-bug-and-have-it-appear-as-a-sub-task-under-the-related-story-on-the-agile-board?page=1#188056

[Deleted user]

Hi Phil. You are 100% correct. There are 'Bugs' that are identified in QA during the Sprint that need to be fixed before the story is 'Done', these should be Sub-tasks as they are a requirement for the Story to be 'Done'. There are however other scenarios as you described where a Production Bug is reported to us by say the Production Support Team, this is Backlogged and prioritized by our PO. When ready it is pulled into the Sprint, as a top level Issue and in SP2 we break it down into Sub-tasks. Both theses scenarios need to be supported. I would like to be able to create a Bug as a 'top level' Issue or a sub level' Issue as necessary.

See also: https://answers.atlassian.com/questions/187663/how-do-i-create-a-bug-and-have-it-appear-as-a-sub-task-under-the-related-story-on-the-agile-board

[PhilB]

Yes, this is a good point. Jira makes a strong distinction between top-level issues and sub-tasks and that can seem confusing at first. I frequently see requests from clients who, for instance, would like the bug issue type be able to be both a top-level issue type and a sub-task. That way users could create bugs at any level in the project. Bugs could be children of a story or they could be completely standalone (not associated with any story). Jira doesn't allow you to do this.

On the surface that seems like you'd want to be able to add a bug as a sub-task but given some additional thought, it raises some interesting issues. Consider the following series of events: A story is added to the backlog, slotted into a sprint and tasked out by the developers. All those tasks are completed, the product owner reviews the completed story and agrees that the story is complete. All sub-tasks of the story and the story itself are now marked as complete. Now...someone finds a bug and opens a bug as a child of the story. Is the story still considered "done"? It has a sub-task that's not done (the bug) so maybe that means the story suddenly went from "done" to "not done". If its no longer considered "done" what does that mean to things like story point burn downs for completed sprints? The list of questions goes on...

It seems like a much better policy to say that bugs are always top-level issues and they can be linked to the stories they impact. Not as easy to do but it avoids all the nasty conflict that arise from having the ability to add a sub-task to an issue that's already marked as complete.

[Deleted user]

Eric, I understand your frustration here. If the subset of a "Story" was a "Task" (like in Scrum it is supposed to be) then it would make sense to have these Tasks appear under the related Story. However in Jira they decided to call these Sub-Tasks. A Task is a top-level Issue, similar to a Story.
What I would like to know is how do I create a Bug Sub-Task to appear under the relevant Story? I want to create a new Issue for a Bug that QA picked up. The Story is not complete until all bugs are fixed, definition of Done. So QA create a Bug (in Jira or Zephyr) and it appears as a top-level Issue on our Backlog, it is moved into the Sprint and appears as a new Issue. I can manually link it to the related Story but I want this Bug to appear under the Story as a Sub-task, it should not be a new top-level Issue, it is a piece of work that has to be completed before the Story is Done. How do I do this, or what am I missing? I am aware I can convert the Issue to a Sub-Task but this messes up the QA Manager's reports and it is unnecessary overhead to have to do this for every Bug. Is there not a better way of doing this?

[bob ebenze@hotmail.com]

Finally - someone who sees it the same way I do. I find it frustrating that I cannot automatically associate a bug to a Story, but only via a link. But then have to deal with the seperately, and the story's status (done or not) is not really related to the bug.

I guess just something that I have to live with for the moment, until enough voices decry that they want something different.

[Ram Muthiah]

Eric, epic consists of multiple stories. Each user story can have technical tasks (aka sub-tasks). Do not worry about adding bugs, improvements, etc., at this point. Keep it simple.

Epic -> User Story -> Sub-tasks

Phillip provided useful answer. In my backlog, sub-tasks do not show up. Only stories show up in the backlog. If you want to add sub-task to the story, go to the story and click "More", then "Create sub-task". I think you are missing this point. If you follow this process, you will see sub-tasks show up in "Work" tab, but not in the backlog.

I keep bug as user story. Bugs are not sub-tasks. If you are doing only development, bugs type won't even come in the picture.

[Renjith Pillai]

Eric,

I look at this in the following way:

• Story is not usually composed of bugs, it is composed of tasks that are needed to implement the story. I am not sure how there can be be a bug even before implementing a story.
• Bugs that are discovered during the story development is left to the discretion of the team to either record as a new sub-task (create a sub-task issue type called Bug) or just get it corrected (it is an overhead to create sub-tasks if they are correcting it there itself)
• A story can be completed only of all the sub-tasks are corrected including bugs discovered during the sprint
• Anything else that are discovered after the story is completed, should be recorded as a new Bug (which is a normal issue type, not sub-task). These are the bugs tha can happen anytime after the story is implemented , for example from integration tests with other systems, customer tests etc. (also depending on your scope of DONE definition)
• These are the bugs which gets planned into a later sprint and you need to have a way to associate them with the original story and for that use Issue links (link type - affects)