Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
share|improve this question

closed as too broad by gnat, Bart van Ingen Schenau, GlenH7, Dynamic, MichaelT Mar 6 at 2:04

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

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 Oct 2 '12 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. –  Hari Seldon Oct 2 '12 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 Oct 3 '12 at 9:14
1  
surely @HariSeldon should just use psychohistory to predict what workflow will be needed ;) –  jk. Oct 3 '12 at 11:23
1  
+1 to @jk... To properly use psychohistory for workflow analysis, I would need a good "Foundation" first :) –  Hari Seldon Oct 5 '12 at 21:49
show 2 more comments

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
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? –  Hari Seldon Oct 2 '12 at 21:01
    
@HariSeldon done. Hope this helps! –  Mike Brown Oct 2 '12 at 21:19
add comment

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.

share|improve this answer
add comment

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