JIRA Hygiene & Best Practices

Introduction

We LIVE in Jira! As such, let’s make sure we are using these best practices with creating issues and project management for cohesion and collaboration. We also want to make sure we are moving projects/issues along at a steady pace. Transparency of project status is important both internally for accurate metrics and externally for our clients to have the most up to date information.

Important things to remember:

1. Jira is directly related to all our internal metrics. Inaccurate information in Jira = inaccurate information in our ongoing metrics. Metrics are used to make improvements to our processes, and if our information is inaccurate we can’t make well-informed and constructive decisions;
2. Collaboration is key as a fully remote team. Time developing fully fleshed out specs is just as important as the time to complete the project.
3. High quality writing applies to internal systems just as much as client-related documentation and products.

This is a living document! If you think of something to be added, please create an issue under the Documentation project, with a Documentation issue type, create a spec, and send it to the Operations team!

Just like writing out specs, planning out your project steps into separate issues with a general timeline, i.e. roadmapping your project, is as important as project completion itself:

• Use. The. TEMPLATE. This makes life so much easier, promise.
• Check out the video instructions for uploading roadmaps using the template into Jira.
• Make sure to share settings with an existing project: TEMPLATE
• Before roadmapping, be aware of the project workflow you will be following, and incorporate the correct statuses as cleanly as possible.
• Be very thoughtful about the sprints and releases while roadmapping.

For client projects, our goal is for all issues to be planned to future sprints while roadmapping. This helps us to keep a pulse on future workloads. Any issues in the backlog (i.e. not assigned to a sprint) should be attended to as soon as possible, and either assigned to a sprint or removed.

It is most likely the case that issues in your backlog are for internal Gradient work, and that you will pull the issues into a sprint should you have the bandwidth.

Best practices for maintaining your backlog:

• Review your backlog often when working on sprint planning.
• If there are issues hanging out that aren’t applicable anymore, delete them. Keeping a clean backlog makes your project planning and sprint planning so much easier!
• Out of sight = out of mind, another reason to review your project backlog on a very regular basis.

There are a variety of issue types within Jira, each one serving a specific purpose and designed to guide you through the work you are setting out to accomplish. When creating a new issue, the issue type will likely default to Story—this is the most open-ended issue type and is essentially a blank slate for you to enter information on what needs to be done.

While Story issues are used frequently and can be useful, we have also created a number of other issue types that pre-populate the most common tasks that need to be accomplished for different types of work. All issue types other than Story automatically populate with Smart Checklists (details below). A primary benefit to using these issue types instead of always creating a Story from scratch is that they have these Smart Checklists. Use a specific issue type other than Story as much as you can.

The Jira Issue Types and Smart Checklists document outlines all of the different issue types and the Smart Checklists that populate within them, for easy reference.

Example issue types:

• Synthesis: Ghost Deliverable
• Survey: Data Collection
• Handbook Documentation
• Project Startup
• Project Closeout: Research Managers
• Project Closeout: Operations

As mentioned above, most issue types other than Stories contain pre-built checklists that outline the most common and highly important tasks that need to be completed for certain types of work. This helps make sure nothing is overlooked. The Jira Issue Types and Smart Checklists document outlines all of the different issue types and the Smart Checklists that populate within them, for easy reference.

As you work through an issue, items can be marked as In Progress, In Review, Done, or Skipped (if it’s not necessary or applicable).

We are continually working to improve these checklists, if you find something that should be revised, added, or removed, please pass it along to Operations!

Specs are as important as the time taken to actually make progress on an issue.

To help surface any ambiguity around what an issue needs to accomplish as early as possible, it’s strongly recommended (dare we say, required) to complete the specification phase by the end of the first day of a sprint. In doing so, every team member involved in an issue has an opportunity to share their expectations for what the issue will produce, how it will be done, and by whom.

When does an issue require a specification? This is a slightly subjective answer: whenever you, as an issue owner, have doubts that the output of the issue may not exactly comport with what the end-user of the issue’s output will expect. Link to all documentation that is relevant to the spec and issue.

Visit WTF is a Spec? for more details on how to properly spec, and to view examples.

When working on an issue, it’s important to update the Status as you go. Making sure the it is an accurate reflection of the current status of the issue allows you to better manage your workload—keeping tabs on what still needs to be done and what’s already completed—as well as identifies for the team where your workload stand.

The status also affects project progress tracking and internal metrics. Additionally, if used for client-facing dashboards, we want this to be as accurate as possible!

All issues move through the same status workflow:

• To Do
• Specification Written
• Specification Approved
• In Progress
• In Review
• Done
• Blocked
• Cancelled

A few notes on best practices:

• If an issue is being reviewed, change the status to In Review.
• If your label is “Blocked” then your status should also be Blocked.

Who should approve? The person with the most knowledge about the issue or your collaborators on the project.

The Label field is very, very important. The information in this field is how we pull our reports for the standup each day and additional metrics. The Standup label is used to filter our issues during our daily standup meetings; all other labels are optional and up to the user to use as they see fit, but they can help to specify exactly why the issue is being raised at standup.

• Standup: If you do not have this label on your issue, it will not show up during our daily standup meeting! Use this label every time an issue needs to be discussed for collaboration purposes or if it needs to be raised for any reason when we gather together at the beginning of the day.

• Review: Add when the issue is raised at the standup meeting specifically because it requires a review from someone. Make sure to remove the Review label and the Standup label when review has been completed or no longer necessary.

• Collaboration: Add when the issue is raised at the standup meeting for collaboration purposes. Make sure to remove the Collaboration label and the Standup label when the collaboration has been completed or is no longer necessary.

• Problem Solving: Add when the issue is raised for problem solving. Make sure to remove the Problem Solving label and the Standup label when the problem solving has been completed or is no longer necessary.

• Blocked: Add when a project is blocked by circumstances beyond our control, ex. waiting for a response from the client, nothing can move forward without additional information. This is important since we want to make sure we have a record of why an issue may not be moving forward. Remember to remove the Blocked label when the issue continues through the workflow!

Issues should be marked with the appropriate level of priority in relation to the other issues in your sprint. Consider how urgently (or not) an issue needs to be completed, the level of impact (internally and externally), what needs to be tackled first, etc. Putting issues in priority order will help guide your attention to what is most important first.

• Highest
• High
• Medium
• Low
• Lowest

Recurring issues should be created when you have a project or issue that is repeatable on a regular basis. A good example of recurring issues are the Month End Close issues for Operations.

It’s easy to create recurring issues with very short descriptions, since it is something you have done over and over again, but don’t leave anything out! These issues may have to be assigned to someone else (due to PTO or shift in procedure) so instructions should be clear.

Think through what will need to be reviewed by another team member (Surveys, Ghost Decks, Memos, etc.). Review issues should be created that will be assigned to the person doing the review.

Estimating story points is inherently difficult. Humans are proven to be really bad at estimating how much time and effort a task will take. But, we still need to try. While story points and sprint planning are components of an agile approach, Gradient has tailored our usage of SPs to primarily highlight the time an issue takes as opposed to a strictly effort-based measurement.

• Individual well being and workloads: Our tracking of estimated story points directly leads to a more accurate picture of our capacity. We can balance workloads and better support PTO.
• BI metrics: We look at operational metrics quarterly in order to have a clearer grasp on the state of the business. We need to be confident that these metrics are as accurate as they can be so we can make business decisions, know what to sell, how to price it, and how to run it. Many of the metrics calculations include story point data.
  • We need to know how profitable each actual story point is so we can assess profitability by client / segment and project type.

There are two story point fields in Jira: Estimated and Actual. We use the ESP field for forward-looking planning purposes, and the ASP field is backward-looking to capture what the reality was after an issue is complete. The goal here is solely to LEARN how much time certain types of issues take us, so that we can continue to refine how we sell and run projects.

When creating an issue, you only need to fill out the Estimated Story Points field. When an issue is marked as Done, you’ll be prompted to fill in the Actual Story Points incurred.

Gradient operates on a weekly sprint schedule. Each Monday we gather as a team and conduct “Sprint Planning” where all work for the upcoming week is reviewed. We use this time to align on priorities, balance workloads, and identify issues that will require collaboration. Prior to the start of Sprint Planning, everyone is responsible for updating the issues in their sprint, coming to the meeting ready to share with the group.

Sprint planning targets and considerations:

• 32 Points: The individual target of 32 estimated story points per sprint will remain in place.
• Issue Complexity: We should consider the types of issues and their complexity, in addition to their ESP value. It’s recommended that each person only has one highly complex issue per week.

Since we operate on a weekly sprint cadence, we should try and have issues represent the work to be accomplished in one week. As best as you can, break issues that would normally take multiple weeks to finish into smaller pieces—this gives you a more manageable and clear path for completion. If an issue begins to span multiple weeks you can manage this a few ways, do whatever works best for you:

Note for issues that roll into subsequent sprints: Be sure to account for ALL story points (over all of the weeks it was worked on) in the Actual Story Points field for an issue that has spanned multiple sprints.

All issues should fall under a release. This keeps things organized when sprint planning, helps reporting and filtering for metrics tracking, and it is a very satisfying moment when you can release a Release!

Jira automatically creates the releases listed below as these are largely standard across our client projects. Use these releases when building your roadmap, and if one of them is not applicable to your project (e.g. Quantitative Design), feel free to remove it.

Jira Releases and examples of what should typically be captured within each:

• Admin: Project setup, budgeting, and internal logistics
  • Project setup in Jira
    • Note: The Project Startup issue will likely be created in a New Business project, and that’s totally fine! No need to move it to this release in your new project once it’s set up.
  • Internal team onboarding
  • Budget approval / tracking
  • Timeline management
• Survey & Data Collection: Creating and launching the survey
  • Survey drafting
  • Contractor hiring
  • Survey programming
  • Survey review
  • Fielding and data collection management
• Qualitative Design: Collecting qual data
  • Catch-all for all qual-related work
• Analysis: Processing and analyzing the collected data
  • Data cleaning, scripting, etc.
  • Plot creation
  • Dashboard creation (e.g., Crunch, Periscope, simulators)
• Synthesis: Developing insights and recommendations
  • Ghost deck creation
  • Final deliverables
  • Presentation prep for client readouts
• Ad Hoc Requests: Handling out-of-scope client requests
  • Handling client-specific requests outside the original scope
  • Category for any deliverable that is requested after the final deliverable

Callouts:

• Create releases with long term goals in mind.
• Yes, you can create placeholder releases that will never be released, especially for internal projects and issues, ex. HR-related Issues.
• Remember to release a release when done!

Fibonacci Agile Estimation

Atlassian: Jira Software best practices