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.
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!
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs