I am migrating my team from a snarl of poorly managed excel documents, individual checklists, and personal emails to manage our application issues and development tasks to a new JIRA project. My team and I are new to JIRA (and issue tracking software in general). My team is skeptical of the transition at best, so I am also trying not to scare them off by introducing something overly complex at the start.

I understand one of JIRA's strengths to be the customized workflows that can be created for a project. I've looked over the JIRA documentation and a number of tutorials, and am comfortable with the how in creating workflows, but I need some contextual What to go along with it.

  • What makes a particular workflow work well?
  • What does a poorly designed workflow look like?
  • What are the benefits/drawbacks of a strict workflow with very specific states and transitions to a looser workflow, with fewer, broader defined states and transitions
  • 2
    Why not take this question to your team? Build a workflow together - that way, you will get something that everyone agrees on. Setup regular reviews of the workflow, so you can change it.
    – Oded
    Commented Oct 2, 2012 at 20:32
  • Long Term, that will definitely be part of the process. Short term however, I need to produce something that will work and is basic enough so that they can see the benefit of using the process in general. Commented Oct 2, 2012 at 20:57
  • 1
    If you want best practice advise for some of the things to consider when setting up projects, take a look at this ebook: geminiplatform.com/Definitive_Guide_to_Project_Tracking.pdf
    – Mark PM
    Commented Oct 3, 2012 at 9:14
  • 1
    surely @HariSeldon should just use psychohistory to predict what workflow will be needed ;)
    – jk.
    Commented Oct 3, 2012 at 11:23
  • 1
    +1 to @jk... To properly use psychohistory for workflow analysis, I would need a good "Foundation" first :) Commented Oct 5, 2012 at 21:49

2 Answers 2


I'd start with three steps. To do, in progress, in production. Let the other states and transitions evolve as needed.

This technique is known as "paving the cow path" Rather than determining up front the most optimal approach to a new process...let the process evolve naturally.

To give an example of some steps you might fold into your process down the road, In Progress to In Production are very broad strokes. You might want to identify steps between the two such as: In QA, In UAT, and Ready for Deployment.

Essentially, I'm nudging you toward Kanban, David Anderson's book is a great resource for learning and leveraging it in your organization.

  • Thanks for the link. Can you expand a little on the second part of your answer. What sort of things should I/we be looking for, down the road, in deciding whether something would need to be folded into the workflow? Commented Oct 2, 2012 at 21:01
  • @HariSeldon done. Hope this helps! Commented Oct 2, 2012 at 21:19

We use Jira with an overly complex/customized work-flow thats supposed to be good for a small one man iOS game through to the next space shuttle deployment. Even as a team leader I cannot do things without getting an administrator involved. I cannot for instance, roll a defect marked as "fixed" back one step to "in action", so if I (or a team member) "fixes" a defect and then sees its not really fixed, it's off to an admin to get Jira fixed. Don't do this - your team will be justified in there skepticism.

.....Thats not Jira's fault.....

Things to keep in mind. Jira is a tool to enable people to get their work done. As soon as it stops that happening, it's not doing what it is supposed to.

Jira has powerful reporting features - use them rather than work-flow that hinders getting the job done.

People normally want to do the right thing - make that easy. People sometimes have to do the wrong thing - make that possible. Use reporting and audit rather than command and control. e.g. "You should not be able to close a defect without it being verified by the test department, but the customer and CEO have decided the fix must go out today." - Developer closes defect and puts in comments "By Order of CEO"

Above all - KISS, It's not rocket science. Not every edge case need a custom way to deal with it - don't - edge cases are better deal with though comments and flexible work-flow.

Not the answer you're looking for? Browse other questions tagged or ask your own question.