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 think that I now better understand your workflows. In our workflow, we do break a story or task apart in sub-tasks; so to me this approach is natural. Before you throw away the subtask approach ...

I suppose that you don't need to break apart the 1000 tickets now. Can it be done when you actually tackle the ticket? Are you aware that some free add-on exist to manage multiple sutasks. The Quick Subtasks add-on is nice and also allows for the use of templates. So you could create a template with all the required standard subtasks and create them all in one single click.

May be you can also consider creating a single workflow with everybody's steps. Allowing more rigid transitions for certain states. E.g. NotStarted -> Prework -> In progress -> QA -> Doc -> Resolved -> Verified -> Closed. You can go to Closed from Doc, InProgress, Verified or QA but can only go from Resolved to Closed via Verified. This way, this workflow could satisfy all of your requirements. You could also try to create one workflow per issue type. Finally, if your team members have a tendency to work separately, you could create multiple Rapid Boards on the same workflow. You can create a board with just the columns that you need which watch a particular portion of the workflow.

Yves

[Steven Hughes]

Thanks for the suggestions. We are going to try subtasks for a sprint or two and see how it goes.

[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!

[Steven Hughes]

Hi Whyves, thanks for the response. Here is some more information. Not all of our tickets go through the same workflow. Here is our current worflow for the most common ticket types.

Story workflow: NotStarted -> Specs -> Implementation -> QA -> Doc ->Closed

Task: NotStarted-> Prework -> In Progress -> Closed

Bug: NotStarted->In Progress -> Resolved->Verified->Closed

One approach to make our process work better for GreenHopper would be to make a general work flow like this.

NotStarted -> PreWork -> In Progress -> QA -> Closed

For a Story PreWork might mean write specs/requirements. For a task, PreWork may mean something more general.

One issue I have with the subtask approach, is that we already have nearly 1000 tickes. Creating a 3-4 subtasks for each ticket seems unmanagemable, like our tools are driving how we work instead of supporting how we work.