Jira workflows - agile - steps, statuses or something else?

[Craig Wright]

Hello. I'm a complete noob to creating workflows (in Jira or elsewhere) and am growing increasingly confused by the jira documentation, videos, etc., online. Hopefully, someone out there can help get me back on track.

I need to create a workflow for creating documentation (Confluence). I have the process of what the writer needs to do and what the reviewers/approvers need to do all planned out. The problem is that I can't figure out how to translate that into a jira work space.

For example, let's say we go from Open to Assign to Writer to Create Content (Create Content consists of plan, research, write) and then on to review. Should there be a separate status for plan, research and write, or should there just be a Create Content status that is associated with In Progress (and the steps within Create Content not mentioned at all)?

Any advice is much appreciated.

[Nic Brough -Adaptavist-]

I'd break this down a bit.

First, I'd take your last paragraph - before trying to create a Jira workflow, map out what you want in the real world. I generally scribble out a simple flow chart, which lends itself to Jira workflows anyway - each circle is a status and each line between circles becomes a transition.

When you're deciding what status you want to flow through, you need to bear in mind your reporting and how each team is going to work. I usually think of two things at this point for each status. The first one is about what the process really is from a user's point of view. In your case, you decide something needs writing and create an issue for it (status Open) - that's easy. But the next step is less obvious. You want to assign it to a writer. The question here is down to whether you're happy to simply assign it to the writer and leave it "open" so the writer knows it's in their queue, or you actually need to know that it's no longer "open" and has moved a step forward - if that's the case, you need a status like "in writers queue". Either way, the next step is easier - decide whether the writer should just go straight to "I've done it, give to reviewer" or they should have an "in progress" status, and then when they've finished writing, say "I've done it, give to reviewer". You then need to make the same decisions from a reviewer point of view - do they need waiting/in progress/complete, or just waiting/complete.

Before you jump one way or the other though, think about your reporting. How do you want the question "what is happening in the queues" - is it useful to know something like 10 open, 20 assigned to writers but not started, 5 being written, 17 waiting for review, 4 under review and 92 complete? Or the more simple, 35 open, 21 in review and 92 complete?

The second thing I think about is a lot easier - the names of status. You need something indicative of what is happening with the issue, and the easiest way to do it is make your status names fit the pattern "This issue is <status>" - if the sentence formed by that is clear, you have a good status name.

Next, you convert your lines to transitions - again this can be quite straightforward, but people often forget to account for non-ideal flow. Think about re-opening items and if things fail reviews. You'll always want at least one transition out of every status to avoid dead-ends. Think about using conditions to control who can do what (e.g. reviewers can't move things into review, and writers can't sign off on reviews)

As for naming transitions, try to think of them as action/verb words. Again, wedge it into a sentence - "I want to <transtion> this issue"

Finally, a quick note on steps and status - steps are a skeleton to hang a workflow off. Users won't see them. I try to keep the step names the same as the status they are for, but don't worry too much about it - status names matter, step names don't.

[Craig Wright]

Thanks Nic, that was very helpful. I decided to ignore steps completely for now and work in the diagram editor, focusing on statuses and transitions. I now have the flow I want with each status representing a task. Previously, I was getting confused by the statuses meaning the status of the ticket...as soon as I thought about them as tasks, it became clearer. That's assuming I've done it right, of course.

Visually, I have the flow I want, so that it part-way there at least. The problems I now face are:

*I have open and repopen as a blue, start status; the resolved and closed as green, close status; all the other parts of my process as yellow, in progress statuses (all named appropriately). I've assumed that associating a custom status with In Progress means that JIRA treats it in the same way as the default In Progress status. Please tell me this is right!

* Part of my process is optional, depending on the resources that are available. How would I represent that on the diagram?

* For screens, am I right in thinking that I need one for every transition hand-over where the recipient needs more than just a status change? So, for example, I'd need a reviewer screen so that the reviewer can tell the writer what changes need to be made.

*Can I continue to ignore steps in the way I have?

Regards

Craig

[Nic Brough -Adaptavist-]

Um, I'm not sure that's quite what I meant. The Status IS the Status of the issue, not so much a taks, but I suspect that I'm just being a little fussy with words. Anyway

1. The colours sound right - I tend to think of blue = needs looking at, yellow = we're doing it, and green = yep, done. So I think you've got a match there.

However, no, just naming a status "in progress" doesn't have any effect on it's behaviour. You still need to define all the transitions into and out of the status (to and from other status). But thats' the flexibility in the workflows - you're free to do quite a lot with them.

2. I've not really mentioned it before, but now you've got a workflow, you need to look at each transition and think about who should be able to do it AND if there are any prerequisites. I strongly recommend you do this because if you don't, then the default stance is to let *anyone* perform a transition, even if they haven't logged in! The thing to look at here is the "conditions" on each transition. At the very least, you want to add one that says something like "user must be in the role of user in the project" to limit it to logged in users, but you can use others as well. You could look at implenting things like "and field X must be filled".

But, I'd also look at "validators" for this. A "condition" will stop the transition appearing. A "validator" will let the user in, and then check fields (which they could add/update after starting the transition) before committing the change.

3. Yes, although I'd add you can reuse screens, and it's worth trying a screen with no fields, as that will let you add comments, which might be enough for your reviewer feedback

4. Yes, the workflow designer (the nice diagrammy thing) pretty much hides the steps from you nowadays. If you use the text view, you'll need to understand them, but in the designer, I don't think you need to think about them at all any more.

[Craig Wright]

Thanks for that. I'm a little confused on the part about In Progress...Let's say I create a status called 'Create Content' and set it to be the In Progress type. Does this just mean that onthe ticket, the 'Create Content' status appears yellow to indicate that it is an In Progress type of status? There's nothing smarter than that going in in the background - it is just a colour association thing (meaning each custom status has to be associated with one of the default status colours?)

I'll look into the conditions and validations issues. I need to get my head around the difference between them.

Thanks again. At least I know I am on the right track now.