If you haven't seen Jira Hygiene & Best Practices for Minimalists, read that first!

Get Even More Refined

If you're interested in being even more accurate with predictions, below are some of the simplest additions you can make that have seen the most impactful improvements. Notice that some Agile darlings like "Story Pointing" is not on this list! We've found that the value to time trade-off is relatively low, so you'll only see the highest impact changes here.

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.

General

Linking

• 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

Assignees

• 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

Content

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

Workflow Status

Stages

• 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

Epics

• 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

Updates

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

‍