Basic question on approach when creating workflow

[Ruben Becker]

Hi,

New to Jira and am setting up a custom workflow for our software development cycle (non-agile). Any suggestions would be most appreciated.

The basic workflow steps might be something like this:

[Creating requirement]

[Creating Design Spec]

[Developing Code]

[Reviewing Code]

[QA'ing Code]

[Done]

In addition, since the process won't move directly from one step to the next (for example, after the design spec, there probably would be some period of time before coding started), I was hope to have some sort of a [Waiting] step. Rather than having several different distinct wait steps (e.g. waiting-to-start-coding, waiting-for-code-review-to-start, etc), I was hoping that I could have one generic wait state, just as the sample Jira basic workflow has [todo] step which multiple other steps can feed back into.

However, I want to be able to control for a given task, that when it transitions from the [Waiting] state, it can only go to the appropriate next step (for example, after completion of design spec, the only transition out would be to Developing-Code -- one could not transition to Reviewing-Code, etc). I can see how to create the unique and appropriate transitions to go to each of the next steps from the Wait step, but I don't see how I can control that only the appropriate transition is presented to the user to select.

Any suggestions most appreciated. The simple alternative is to create multiple distinct wait steps between each, but this seemed like it would unnecessarily clutter up the workflow.

Thanks much!

[Tanner Wortham]

i always suggest that simple is better. less is more. that kind of thing. so i think you're right in not cluttering up your workflow, but i understand what you're after. the language you use in your workflow can get you ensure your users understand or confuse the crap out of them causing hours of individual conversation. picking just the right terminology is important, and that terminology should be succint. it can be challenging. additionally, i try to define workflows by thinking of it one of three ways:

1. Name your steps as if you're at the beginning of the step.
2. Name your steps as if you're at the end of the step.
3. Name your steps as if you're in the middle of the step.

Here's some simple examples:

• Beginning naming: To Create Requirement -> To Create Design Spec ...
• End naming: Requirements Created -> Design Spec Created ...
• Middle: Creating Requirements -> Creating Design Spec

Each has its advantages but based on what you say above, the "beginning" method might fit what you're after. Of course, you'll need to emphasize to your users that just because it says "To Create" doesn't mean there's an interim step. it just means they can't advance until all their work is done for the next one.

of course that doesn't really answer your question because you want to know how long something might have been on hold in between steps, right? in that case, i would suggest against using your workflow. instead, use the updated field in JIRA to know when the last time an issue has been action. or analyze it by looking at when time was last logged to an issue. oftentimes people wish to use workflow to capture all interesting information, but i try to only modify workflows as a last resort for reasons of simplicity.

[Ruben Becker]

Thanks very much for all the insights, Tanner.

Yes, I see your points and also, as you mention, was wanting to try and "capture" down time as represented by residing in the wait step. Using the updated field sounds like something to pursue but I was hoping to keep this workflow lightweight and minimize the interaction that developers would need to have with it, and that would seem to increase the interactions as the develolpers continued to update -- i.e. was not expecting a developer to keep updating while in the "coding" step but with your approach, that could imply "idle."

I guess there's no simple way for this wait step to enforce which step is transitioned to based on the predecessor (i.e. an issue which came from "Writing Design Spec" would only be able to transition to "Coding", etc).

Thanks much!

[Tanner Wortham]

ah. i had assumed your developers would be logging time to their issues causing the update date to become current. or possibly they'd be tagging others in issues as they had questions, which also updates the update date. were those poor assuptions?

[Tanner Wortham]

for the record though, what you're suggesting is likelypossible through the "Previous Status Condition" that is available while authoring a workflow. if you don't see it, it probably came with one of our addons. likely "JIRA Misc Workflow Extensions" that we have installed.

i've never tried to use it myself though.

[Ruben Becker]

Hi Tanner,

Thanks so much for the additional pointers, but yes, the assumption that developers were going to enter time was not the way we had planned to go. We were hoping to keep the interaction for them more lightweight.

I'll take a look at the Previous Status Condition you mention and see where that gets us.

Alternatively, if there was a way to use %-of-completion on a per-step level in addition to as an overall % on the entire 'issue', that would work for us, too, but I don't this that that's available. What I'm saying is we'd dispense with all the individual inter-step wait states and then just have a %complete of each step so that if the 'In-Coding' step was at 0%, we'd know it was essentially waiting and hadn't started.

Thanks again.