# Shopify Development Ticket Templates You Can Reuse

> Shopify development ticket templates for bugs, features, and enhancements, with acceptance criteria examples for each, ready to copy into your tracker.

_Published: 2026-09-07 · CommerceCopilot_

## Why a generic ticket template doesn't hold up on Shopify work

Most ticket templates are built for software in general, and they show it the first time a Shopify team tries to use one: a generic template has a field for "steps to reproduce" but nothing for which theme section is affected, or a field for "priority" but nothing for which Liquid template or app touches the change. A Shopify development ticket template needs to account for what varies on this platform: theme sections and their schema settings, app-injected code a developer didn't write and can't always see in the theme editor, and the gap between what a merchant can change themselves and what needs a developer.

The three ticket types covering nearly all Shopify agency work, bug, feature, and enhancement, each fail differently when the template is too generic. A bug ticket without a clear "expected vs. actual" split turns into a debate about whether something is even broken. A feature ticket without explicit scope boundaries turns into a two-week build for what was quoted as three days. An enhancement ticket that reads exactly like a feature ticket loses the one distinction that matters: whether existing functionality is being improved or something new is being built from nothing.

These templates assume the acceptance-criteria and scope discipline covered in [how to write development tickets a Shopify team can build from](/blog/how-to-write-development-tickets). What follows is the reusable structure for each ticket type, with a filled-in example, so a team can copy the shape directly into whatever tracker they run, [including Jira](/blog/jira-for-shopify-agencies).

## The bug ticket template

A bug ticket exists to answer one question fast: is this actually broken, and under what conditions? Everything in the template should serve that question.

```
Title: [Page/component] does [wrong behavior] when [condition]
Expected: what should happen
Actual: what happens instead
Steps to reproduce: numbered, starting from a clean state
Environment: theme (live/unpublished), device, browser, logged-in state
Affected section/template: the specific Liquid section, template, or app block
Severity: blocks checkout/purchase, visible but workaround exists, cosmetic only
Screenshot or recording: linked, not described
```

**Example:**

> **Title:** Cart drawer shows $0.00 for line item price when a discount code is applied
> **Expected:** Line item price shows the original price, with the discount reflected only in the subtotal.
> **Actual:** Line item price itself shows $0.00 once a discount code is applied, on every product in the cart.
> **Steps to reproduce:** 1) Add any product to cart. 2) Apply discount code SAVE10 in the cart drawer. 3) Observe line item price.
> **Environment:** Live theme, desktop Chrome, both logged-in and guest.
> **Affected section/template:** `sections/cart-drawer.liquid`, line-item price snippet.
> **Severity:** Visible but workaround exists (subtotal is correct, so checkout total is unaffected).
> **Screenshot or recording:** [linked recording]

Severity is the field that gets skipped most often, and it's the one that decides whether a bug gets picked up before the next release or sits in the backlog for a month. "Blocks checkout" and "cosmetic only" are not the same ticket, even when the steps to reproduce look identical in length.

## The feature ticket template

A feature ticket covers something that doesn't exist yet: a new page section, a new checkout step, a new account page capability. The template needs the same acceptance-criteria and scope discipline as any ticket, plus a place to record the design reference, since a feature without one gets built against whatever the developer imagines.

```
Title: Add [feature] to [page/area]
Context: why the client wants this, one or two sentences
In scope: what's being built
Out of scope: what's explicitly not part of this ticket
Acceptance criteria: a checklist, each line independently verifiable
Design reference: linked Figma frame, not a description of it
Technical notes: affected section/template, any app dependency
Dependencies: any ticket that has to land first
```

**Example:**

> **Title:** Add a size guide modal to the product page
> **Context:** Client's return rate on apparel is high, and support reports most returns are sizing-related.
> **In scope:** Modal trigger link near the size selector, modal content pulled from a metafield per product, close on overlay click or escape key.
> **Out of scope:** Size recommendation logic, changes to the size selector itself, mobile app parity.
> **Acceptance criteria:**
> - Modal trigger appears on all products with the size-guide metafield populated, and is hidden on products without it.
> - Modal opens without a page reload and traps focus for keyboard navigation.
> - Modal content renders the metafield's rich text formatting (headings, tables) correctly.
> **Design reference:** [Figma frame link]
> **Technical notes:** `sections/main-product.liquid`, new metafield definition needed on the Product resource.
> **Dependencies:** Metafield definition must be created before this ticket can be tested end to end.

The out-of-scope line is doing real work in this example. Without it, "add a size guide modal" easily drifts into "also fix the size selector while you're in there," which is a second ticket, not a footnote on the first one.

## The enhancement ticket template

An enhancement improves something that already works, which is a different job than a bug fix (something broken) or a feature (something new). The template is close to the feature template, with one addition: a description of current behavior, so a reviewer can confirm the improvement actually happened rather than just trusting that it did.

```
Title: Improve [existing feature] by [specific change]
Context: why the current behavior isn't good enough
Current behavior: what happens today
Desired behavior: what should happen after this ships
In scope / out of scope
Acceptance criteria
Technical notes
```

**Example:**

> **Title:** Improve collection page load time by lazy-loading below-the-fold product images
> **Context:** Collection pages with 40+ products are slow on mobile connections, and the client has flagged bounce rate on category pages in their analytics.
> **Current behavior:** All product images on a collection page load immediately, regardless of scroll position.
> **Desired behavior:** Images below the fold load only as they approach the viewport.
> **In scope:** Lazy-loading attribute on collection grid images, a low-resolution placeholder while loading.
> **Out of scope:** Image compression or format changes, changes to the product card layout itself.
> **Acceptance criteria:**
> - Above-the-fold images (first two rows) load immediately, unaffected.
> - Below-the-fold images begin loading before they're fully visible, not after.
> - No layout shift occurs when an image finishes loading.
> **Technical notes:** `sections/main-collection-product-grid.liquid`, uses native `loading="lazy"` with a placeholder fallback for older browsers.

## Acceptance criteria examples for each ticket type

Acceptance criteria are the part of any Shopify development ticket template that gets written vaguest, because "it works" feels obvious to whoever wrote the ticket and isn't obvious to whoever reviews it. A few more acceptance criteria examples, by type, show the specificity that holds up:

- **Bug:** "Checkout completes successfully when a customer applies a discount code and then removes it before submitting payment" is checkable. "Discount codes work correctly" is not.
- **Feature:** "New account page tab is visible only to customers with at least one past order" is checkable. "Add order history to the account page" describes the feature but not when it's done.
- **Enhancement:** "Page weight on the product page drops below 1.5MB on the default theme" is checkable, assuming the current weight was measured and recorded first. "Product page loads faster" is not, because faster than what is never answered.

The common thread is a number, a condition, or a state that someone other than the ticket's author can check without asking a follow-up question. If two developers on the same team would disagree about whether a piece of acceptance criteria has been met, it isn't specific enough yet.

## Keeping templates from becoming boilerplate no one fills in

A template solves the structure problem. It doesn't solve the problem of someone actually filling in each field accurately, under deadline pressure, ticket after ticket, across every project running at once. That's usually where a clean template starts producing "N/A" in the out-of-scope field and a copy-pasted acceptance criterion that doesn't match the ticket: templates rot the same way an unmaintained tracker rots, not from a bad structure, but from nobody keeping the structure honest.

CommerceCopilot's Business Analyst agent drafts tickets in this structure directly from the source material, a client call transcript, a Slack thread, a brief, rather than starting from a blank template. It fills in scope, acceptance criteria, and technical notes from what the brief actually says, and flags a field as an open question instead of guessing when the source material doesn't cover it. The [brief-to-tickets guide](/docs/your-first-brief-to-ticket-project) walks through reviewing a drafted ticket before it's confirmed into your tracker, which is the step that keeps the templates above from becoming boilerplate: every field still gets a human check, just not a human first draft.

## FAQ

### Do bug, feature, and enhancement tickets need separate templates, or can one template cover all three?

Separate templates hold up better in practice. A single template either carries fields that don't apply to every type (steps to reproduce on a feature ticket, a design reference on a bug ticket) or gets stripped down to the lowest common denominator and loses the specificity that makes each type useful. The three templates above share a similar backbone, acceptance criteria and scope, but the fields around that backbone are different enough to justify keeping them separate.

### What's the difference between a feature ticket and an enhancement ticket?

A feature ticket covers something that doesn't exist yet on the site. An enhancement ticket improves something that already works, and its template should record the current behavior alongside the desired behavior, since that comparison is what proves the improvement happened. Filing an enhancement as a feature usually just means the current-behavior field gets skipped, which makes it harder to confirm the change actually helped.

### How specific do acceptance criteria need to be for a small ticket?

As specific as it takes for someone other than the ticket's author to check the work without asking a question. A small ticket, like a single copy change or a color swap, might need only one or two acceptance criteria. The bar is whether someone could disagree about completeness, not the length of the ticket.

### Should these templates live in the ticket tracker itself or in a separate document?

In the tracker, as an issue type template or a saved description snippet, not in a separate wiki page someone has to remember to open. A template that requires an extra step to find gets skipped under deadline pressure, which defeats the reason for having one. [A Jira setup for Shopify agencies](/blog/jira-for-shopify-agencies) covers where custom fields like acceptance criteria and affected theme section fit directly into the issue type configuration.

---
Canonical page: https://www.commercecopilot.ai/fr/blog/shopify-development-ticket-templates