Using greenhopper for agile

What is the best practice for using Greenhopper for agile.

We want to represent User Stories and tasks.

Should we use Parent JIRAs and subtasks. If so, there is no Greenhopper view which shows this hierarchy. It seems that everything is flattened as a bunch of tasks but i can't see if a story is closed.

Please advise on best practice or any suggestions here.

thks,
ak

Hi Ak,

very vast subject, and will mostly depend on your team likes and dislikes but here is something to start with:

To Add IN JIRA
1) Standard Issue Type : User Story
2) Custom field Number: Story points
3) Custom field GreenHopper Ranking field: Rank

To Enable IN JIRA
1) Time Tracking
2) Sub-tasks
3) Issue linking (cool)

To Add IN GREENHOPPER (from Project > Configuration)
1) Watched Feilds: Story points
2) Ranking Field: Rank

Now Your CARD Templates
1) In your Story
i) Summary
ii) Description
iii) Status
iv) Version
v) Remaining (Just for the aggregation)
vi) Assignee
Corner Card) Story Points

2) In your Sub-tasks
i) Summary
ii) Description
iii) Status
iv) Version
v) Original Estimate
vi) Assignee
Corner Card) Remaining

For the other issues I will leave it to you

Now you are set for a good start.

Things we do:
1) We use the unscheduled as our backlog
2) We have releases exploded in multiple sprints. (using Master)
e.g
o Release 1
oo Sprint 1M1 (Master --> Release 1)
oo Sprint 1M2 (Master --> Release 1)
o Release 2
oo Sprint 2M1 (Master --> Release 2)
oo Sprint 2M2 (Master --> Release 2)

This way we can have our release burndown charts and our sprint burndown charts

3) If you want to prioritize just set your context "Sort By" with your rank field.
See context doucmentation here: http://www.greenpeppersoftware.com/confluence/display/GH/CONTEXT

4) We create Stories that we estimate in story points
5) We explode the Stories into multiple Sub-Tasks that we estimate in hours.
6) We do our stand up meetings in front of the task board in the "OUTLINED" view.

Here you go, a very very breif resume but I truly hope it helps.

Kind Regards,

PS: try as much as you can to "Keep it simple!!"
Do not create tons of workflows, screens and so on.

Hi,

I have a couple of questions about this approach - I dont understand how you nest sprints into releases - is Master another tool? (Do you have have a release burndown view?)

Also, is there a way to get a roll-up of completed sub-tasks to know that a story has been completed?

Thanks!

Daniel

Hi Daniel,

You can find more information on the master option here:
http://www.greenpeppersoftware.com/confluence/display/GH/PLANNING+BOARD#PLANNINGBOARD-organizing

It is a build in feature of GreenHopper.

For the roll-up, you can customize your JIRA to have this behavior via the post functions of your Workflow.
We cannot force this behavior (although we are relooking at our position on it).

Cheers,

Hi,
Thanks for the information above!
I am using the story point for estimation of both stories (issues) and tasks (sub tasks). The problem is that the story points do not aggregate. For example, the original story points of a story is 5, but after story has been broken down to 3 tasks with 2 points each. The GH do not change the story points to 6. And further more, the total points of iteration is the total of story and subs which is 11.

How do you solve this?

Thank you in advance!

Hi Weiz,

The aggregation in JIRA and GreenHopper was only meant to support the Time tracking fields.
But hey if you really want aggregation whit your points you can.
simply build your own "Story point" custom field that will do the aggregation.
Farely simple to do.

Cheers,

Can Greenhopper be used for planning that spans multiple Jira projects?

We have a number of development teams that each have their own Jira Project. However some of our larger features span two or more of these projects, and I'm not seeing a way to do planning of Jira issues that span multiple projects.

Thanks for any help you can offer.

Sorry GreenHopper is Project based.
You wont be able to do cross projects.

Cheers,

Thanks so much for the quick reply. Is this possibly an item on the roadmap?

I imagine that many companies who use Jira+Greenhopper have the need to do product planning across Jira Projects.

Hi,

The cross project is something that we have looked at in the early stages of GreenHopper. The problem was all projects do not often have the same configurations.
E.g:
1) Workflows
2) Fields
3) Screens
4) Permissions
5) Assignees

Making it more then difficult to handle in a board.
Thus we have abandon the idea.

What we are more aiming to do is to actually offer some facilities like the burndown charts on JIRA queries (that can be of course cross projects)
This is in our backlog, we are just waiting for JIRA 4.0 to come out since this one will offer a much more powerfull search engine that will allow us to do this.

Cheers,

Good stuff. I appreciate the quick response. I will offer that if you're ever interested in speaking with someone about this topic that work with a firm that currently has 13 development projects, and I'd be happy to offer product input.

For example, we're not really interested in viewing a burndown chart across projects (because each scrum team manages their own burndown charts), but we are interested in cross product planning efforts such as ranking user stories across projects.

"simply build your own "Story point" custom field that will do the aggregation.
Farely simple to do"

Is this simple to do?? I would think this would involve some custom code to be written and then integrated into JIRA. If not could post/send me the steps to creating such a field??

Thanks,

At the start of the thread was this:
To Add IN JIRA
1) Standard Issue Type : User Story
2) Custom field Number: Story points
3) Custom field GreenHopper Ranking field: Rank

So, should we remove some of the other Issue Types? Should there still be TASKS, Improvements, and New Features -- or should they all be User Stories?

I believe we will have "Bugs" still, as these are created by a different group for a slightly different reason, but i am curious if there is a best practice around this.

Hi Marshall,

No need to delete the other issue types.
You could simply create your own Issue type Scheme and actually select the issue type that you think you will need.
For instance in most of our projects we use:
Standard Issue Types:
1) Bug (for application bugs on released & shipped versions)
2) Request (usefull if you client can punch in ideas)
3) Story
4) Task (for task unrelated to a story)

Sub-task Issue Types
1) Technical tasks - for the stories (can be the buildin subtasks type of JIRA)
2) Stroy defect - bugs reported in mid sprint/release of unshipped versions

Then when you create an "I wanna be an Agile Project" like you just need to select that Scheme.

You can find the how to create issue types, schemes here:
http://confluence.atlassian.com/display/CONFEVAL/JIRA+Quick+Start+Guide

Let me know if this helps.

Cheers,

Can you use the Taskboard rank field to sort the Jiras that a parent Jira 'Includes'?