Greehopper usage when issues have different owners at different workflow steps

Steven Hughes

We are trying to use Greenhopper for our project and are struggling with how to use the tool effectively for basic planning and tracking activities.

In short, we have different issue types and each issue type has a different work flow. Each step in the workflow is usually performed by a different individual.

Here is our Story workflow(NotStarted -> Specs -> Implementation -> QA -> Doc ->Closed)

When starting a new sprint, say we have 10 prioritized stories. Story 2 will be tested by Judy, and Story 3 will be tested by John, Bill is the best with databases so he will spec Stories 7-9 and Sue is the best at math algorithms so she’ll spec Stories 1-4. Each person needs to know what issues will eventually end up on their plate so they can provide estimates and plan for that work (a tester can write tests before coding is done).

It seems to me that Greenhopper just doesn’t work well for this and it is really hard for me to use to get the complete estimate for a story, and to get people later in the workflow working on anything they can before the ticket gets to them.

Subtasks are really cumbersome solution to this problem because having a subtask for every step in a workflow is overkill, and subtasks are treated a bit like second class citizens in Greenhopper because they don't appear in may views (Plan/Report).

Am I missing something? Is the process above just incompatible with Agile? This seems like basic stuff any methodology or tool should support.

Yves Riel _Okapya_

Hi Steven,

I feel there are some important info missing to give you a very useful answer, especially when you say that you need a complete estimate ... but I will try.

Subtasks are effectively most useful when you break your story into tasks during the sprint planning. When the sprint begins, then every team member takes a subtask and transits it through the workflow. From my point of view, your workflow seems more like a set of subtasks more than a workflow and as such, it makes sense to use subtasks for every "workflow step".

However, if every task really need to go through all the Specs-Implementation-QA-Doc steps then you have a workflow. From what I understand, the thing is that the workflow is not linear as every step can be done in any order (or almost). Therefore, I suggest that you create a workflow with the possible transitions between the different status and assign it to your project. Every status would be a column in the board in work mode. When the sprint starts, the team takes their tasks and move it to a column. When they are finished, they move it back to the open column so that it is available for someone else.

If you want to track what was done so that the team can now when they can take the task, just use a label or use a custom field to indicate the work done. It is easy afterward to create quick filters to filter out the subtasks based on what was done.

Hope that helps!