Initial setup

[Tim Fricke]

When starting out with JIRA is it better to use the JIRA Default Schemes? OR should I be customizing projects? The ultimate goal is to use this for development cycles, bug tracking and project management (across departments).

Any tips, insights, articles to read would be great!

[Nicolas Bourdages]

I don't think I ever used the default schemes. I started experimenting with custom workflows from day 1.

Here's a typical workflow we use for bugs:

• Open, Resolved, Closed, Reopen, Pending, Need Attention
  • Developers set the bugs from Open to Resolved. 
  • QA set the issues Closed to confirm they're indeed fixed, or to Reopen if they occur again. 
  • Pending is the product owner deciding the issue will be fixed later (you could use any term that makes sense to you. "Future" works too). 
  • Finally, a developer or product owner might assign a bug back to QA at Need Attention with a comment explaining that additional details might be required

For Subtasks and other task-like issues:

• To do, Ready, In progress, On Hold, Blocked, To Be Reviewed, Done
  • To do is the default state. At this point, an issue is not estimated and not assigned to anybody
  • Ready issues have a complete description and are ready to be taken by a developer
  • It's fairly self-explanatory what In Progress issues are
  • On Hold issues are issues for which some work was done, but shifting priorities and resource availability has made stopping work necessary.
  • Blocked means that work is stopped because a specific issue is blocking progress. It's a good practice to create an issue for that blocker and link it to the Blocked issue.
  • To be reviewed is used for tasks that require oversight of some kind, like a designer's approval or a code review.
  • Done is when no more work is required on that issue.

Of course, these are rather simple, and we have loads of variations depending on the type of project, issue type and teams. Some teams like to have validators in transitions to force people to comment when setting an issue On Hold or to ensure that all sub-tasks are done before you set the parent issue to Done. Some teams want transition screens everywhere, while others don't want any. Developments projects use workflows more adapted to Scrum, while support projects are closer to Kanban.

I strongly suggest you get acquainted with the advanced workflow configurations, and be on the lookout for plugins that make your lives easier (JIRA Agile, Structure, Scriptrunner, Issue Templates, Quick Subtasks, JEditor, JEMH...). I could go on.

Good luck!

[Timothy]

IMHO, you should leave the JIRA Default Schemes alone. If you need a new scheme, make a copy of it and rename it as you see fit. There is no way to revert it back to the original unless you manually edit it.

Or unless you want every other project created to use the "edited defaults", then go ahead.