Update story workflow state from Greenhopper? (while using stories as swimlanes)

[Doug Varn]

We use stories in Greenhopper each with a variety of sub-tasks (code, test, etc.). I configured the Work board to show stories as swimlanes and their children sub-tasks beneath. The dev team transitions these sub-tasks through their own workflow (open/in progress/done) but in Greenhopper, I can't seem to update the status of the parent story once I see the sub-tasks are active. That is, the story still shows "open" though maybe all the sub-tasks are done.

I want an easy way to update the parent story workflow state from Greenhopper.

Or does a keyboard shortcut for this exist... much like typing "e" for edit or "a" for assign?

[Marten Schukkink · Accepted solution]

If the swimlane is the active issue (blue color, by selecting the swimlane with your mouse or by using j/k to itterate the issues), press "." and type the workflow status (e.g. "Open") you would like to transition to and press enter. Unfortunately there is no way to see the current status of the issue (or the card color) on the swimlane at this moment, that would be a nice addition to greenhopper.

[Doug Varn]

thanks, i recently found the "." shortcut but had no idea it would allow state transitions.

[Mike Borozdin]

is there still no fix for this?

[motherg]

Doug - not sure if this will help solve your issue or not but it might shed some light (I just came across this myself as we're trialling Greenhopper).

Once all the sub-tasks of an issue have been completed, it's time to resolve the issue itself. So when you move the last sub-task to the 'Done' column, GreenHopper will prompt you to move the parent issue too. If you resolved the sub-tasks in native JIRA instead, a button will be displayed on the parent issue the next time you visit Work mode. (Ref)

So....the story isn't automatically transitioned when the sub-tasks are complete.

[Doug Varn]

thanks there. i am aware of that prompt but it doesn't quite fully help. that is, i want to be able to quickly move the story state to say "Dev" when I see one sub-task in progress, and "QA" when they have started. guess i have to do it manually or we're also considering a script to auto-update for us.

[motherg]

I was sure you would have been aware - it just happened to be something I read minutes before seeing your question.

I think we'll also have a similar problem as you when we come to it so I'll be interested to see what solution you come up with.

[Doug Varn]

well, what we do isn't exactly what all do, but i think it's surely the best way. that is, for a story, we break it down into all sub-tasks we can think of, not just for dev team, but qa, really anyone.

in GH, we show each story as swimlanes and the sub-tasks beneath. the workflow for sub-tasks is quite simple: they're Open or In Progress or Blocked or Done.

that said, the story worklflow is different. at a higher level, we have more things that need to happen, depending on the team. our client teams story workflow is something like: Open | Development (means devs and even QA have started) | QA (means Devs signed off and only testing is left) | Design Review (our design team really wants to see it and perhaps make some tweaks before it ships | Product Review (same) | Ready for Release.

kind of a lot for a story to go through, but no way around it with us. anyway, to acccomodate this in GH, the Scrum/Task Board is set up with stories as swimlanes, sub-tasks below, and columns representing Task workflow.

to see Story status from a higher-level, i have another board set up, the "Story board" that doesn't have any swimlanes for sub-tasks and the columns reflect the Story workflow. from here i (or any top-level manager, ahem) can see the state of the story without sub-task details. Is it in Dev still? QA? Product Review? etc.

[motherg]

I don't miss working in an agency environment (or at least that sounds like what you're in - the design review phase isn't something we have seperately at The Guardian because we iterate on it if any changes are required, where as at my previous place we had to do exactly what you're going through).

I think our sub-task workflow will be very similar to you (as is our current bug workflow....they'll probably be treated the same as effectively a bug becomes a dev task in a sense). Stories.....that's the one we're really going to have fun agreeing on - I'm going to try and keep it as simple as possible as we do feature releasing so whenever a story is complete it gets demoed and released - hopefully we won't have too many other states.

I feel for you dude, keeping on top of that cannot be fun!

[Brannon Fay]

We seem to be okay with this process. I automated creation of our sub-tasks using the Script Runner add-on. The Devs move a Story from Open to In Progress with some workflow conditions for required fields checked, then a post function per sub-task to create them. These are common, one extra sub-task for defects to update our legacy system. The rest are all common per our Definition of Done. This means all sub-tasks are now Open, assigned to the assigneed of the Story (one of the required fields in the workflow), Story is In Progress. The Dev then moves the Implementation sub-task to In Progress and begins work.

[Doug Varn]

I don't think it's possible at the moment. It would be nice someday.