Help with the best approach to setting up Jira workflows

[Chris Morphew]

The main thing not clear to me at the moment is what detail to take the workflows to for issue types and sub-tasks and what knock on effects this has in the system. I would very much appreciate any guidance on this as I don't want to set off down the wrong road from the beginning!

For example, I have one overall software project object defined in Jira, and sub objects defined such as 'New feature', 'Bug' etc within this.

Should I set up an overall workflow for the 'New feature' issue type which will relate to a whole project process right through scope iteration, specification iteration, sign off, build, test and release or define a high-level workflow for 'New feature' and create workflow schemes for sub-tasks such as 'Specification'?

Hope you can point me in the right direction!

[Faisal]

Hi there,

Addressing your inquiry on workflow setup here, supposedly JIRA workflow setup should consists of the steps and statuses which are relevant for issues under specific projects. For an example, we can look at the default JIRA workflow setup, whereby issues are created with the status Open which indicates that it is a new issue, and when someone is working on it then we may change the status to In Progress and when the task is done we can Resolve and Close the issue. Applying this to your requirement here, I believe that for the issue type "New Feature", if the mentioned statuses (scope iteration, specification iteration, etc) is part of the processes that is applied to the issue type, then you may configure the workflow to include the statuses as per required. And the same should be applicable for sub tasks issue types as well.

If required, it is also possible for you to create different set of workflows for different issue types, and the workflows can be mapped to issue types in Workflow Schemes.

Anyway for your reference on setting up workflows, you may kindly refer to the following documentation which contains more details about JIRA workflows setup:
https://confluence.atlassian.com/display/JIRA/Configuring+Workflow
https://confluence.atlassian.com/display/JIRA/Configuring+Workflow+Schemes

I hope that the info provided above helps to accomodate your inquiry here.

Thanks.

[Chris Morphew]

Hello, thanks for taking the time to reply! Reading through that information maybe my question is more fundamental and I need to take a step back - if you have any guidance for me it would be great (or point me to an article that details some clear examples of setting up Jira for SDLC as I can't find any!).

So far I have the following structure (not all types are listed, I've just shown a few examples) - can you tell me if this is the right approach?

Projects
----------
One overall project object for now since we have one main software product - i.e. there will only be one entry in the project drop-down in Jira.

Issue types
---------------
Epic [E.g. an idea for a project that hasn't been scoped yet]
New feature [using this as for each new sub-project we begin e.g. 'New report module']
Bug

Sub tasks
------------
Scoping
Specification
Test Plan
[Should bug be here as well since you may wish to relate a bug to a particular sub-project]

Statuses
-----------
Create Scope
Open
Iterate Scope [in progress]
Scope review
Scope sign-off
Scope reopened [e.g. to incorporate a change in scope]

Transitions
--------------
Create Scope
Start iteration
Stop iteration
Submit for review
Submit for sign-off
Reiterate scope

- Looking at this now, I am not sure the statuses and transitions ring true?
- Unsure whether I should be defining several separate workflow schemes e.g. one for scopes and one for test plans etc or build everything into one main workflow that applies to the whole SDLC process.

Sorry for the long post, but I am anxious to get started!

[Chris Morphew]

Anyone have any insight for me? Or perhaps some example workflows for SDLC?

[Nic Brough -Adaptavist-]

That looks fine to me, with two caveats. You have already mentioned both things I'd question though!

First, I'd probably revise the transitions slightly - think of the status as a "useful name for the current state of an issue" and the transition labels as "an action to do to move from one state to another" - many transitions I see are labelled in a way to make it clear to the end use that clicking them will do to the status.

You might also be short of a few transitions - think about any cases where something might move backwards in the process, possibly because something was missed in review or something external changes and triggers a rethink.

Secondly, yes, you definitely want more than one workflow. The workflow you've outlined probably won't work for test plans (or bugs, if you decide you need them)

[Chris Morphew]

Hi Nic, thanks for your reply.

I will have another think about these after what you have suggested. It does seem strange to me that there aren't any templates available online at least to get people started (or perhaps you could select a scheme as part of the install process relevant for SDLC or website development).

One thing that may also be an issue with selecting just one overall 'project' object is that there will be no dashboard view for each sub-project (new features) so the dashboard will just show overall whats going on with everything - I wonder if this will also affect reporting functionality?