Jira Hygiene & Best Practices for Minimalists

Here's our quick list of the simplest ways to make sure the data in your project management tool (in this case, Jira) is updated and representative of the most important bits of information. These were the most common practices across the dozens of companies and hundreds of teams we've worked with. Ensuring this information is included and updated makes the information distributed within the R&D org and outside of it as accurate as necessary for asynchronous day to day coordination.

The first step is usually making the change in Jira so that your team's work is reflective, whether that's fixing linking, statuses, or adding information to fields. It's a good idea to align internally on all the proper adjustments and steps beyond these updates.



  • All epics are linked to the parent initiative
  • Make sure dependencies are linked via “blocked by”
  • If links do not apply anymore, make sure to unlink


  • Add the “assignee” as soon as you know who will be working on a task
  • The assignee of anything “In Progress” should be the person working on it


  • The summary (name of the ticket) and descriptions should have unique information about the work to be done 

Workflow Status


  • Once work reaches a new stage (In Progress, In QA, etc) the workflow status of the issue should be changed
  • If the issue is reopened or no work is being done, then it should be set back to “To Do” or “Blocked” 
  • This includes work that was complete but needs to be revisited


  • Any epics with work in progress should be set to “In Progress” 
  • If an epic is complete, it should be marked “Done”
  • This distinguishes it from epics where all work is done, but there is more to be planned out so is not complete

Work within the 3 workflow statuses should be categorized in “To Do” (gray), “In Progress” (blue), and “Done” (green) 

  • Anything with no active development or work should be a “To Do” category (e.g. backlog, grooming)
  • Anything that requires consistent effort should be “In Progress” category (e.g. development, code review, qa)
  • Anything that doesn’t require active effort and is either in a “monitoring” or complete state should be “Done” category (e.g. Ready for Release) 

Ticketing and Organization

Even when doing research or “spike” work on a ticket, it’s helpful to consolidate that into a ticket to represent that work.

  • Ideally this should be a separate ticket type to indicate this type of work, or it could be labeled with a distinct “Spike” label 

Epics should be one cohesive deliverable and block of work and should be used to represent milestones

  • If the work that needs to be done for this milestone changes, make sure to move tickets around to accurately represent
  • If there are tickets within the epic that are not essential to complete the epic, move them to a follow-up epic


Project Status (RYG, Risk Level, On Track for End of Quarter) should be updated on a weekly basis

Any Yellow or Red statuses should have an explanation of either:

  • Where help is needed
  • What mitigation steps are being taken