What makes for a good JIRA workflow with a software development team?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

I added a comment about best practices when creating a workflow from scratch to the Workflow documentation at https://confluence.atlassian.com/display/JIRA/Configuring+Workflow?focusedCommentId=334430506#comment-334430506

And don't forget the JIRA books, including my Practical JIRA Administration (O'Reilly)