I'm a tech lead and I'm never writing a Jira card again

It isn’t that deep. I’m a dev, you’re a dev (probably), and while we certainly appreciate working on a solution to a well-written card… actually writing them is mega boring.

So, let’s come up with a workflow that makes the computers handle the boring stuff.

Jira card guidelines

Standardize that shit

If every ticket looks different, devs spend more time decoding than coding. Make a template. Stick to it.

Use sections like Description, Definition of Done, Testing Criteria, and Business Value.

(Only) Include the stuff that Gets Things Done

No Definition of Done = tickets that never die.
No Testing Criteria = QA crying in the corner.

They’re not optional. They’re how features go from “neat idea” to “live in prod without a 2 a.m. rollback.”

So, uh, why are we doing this?

“Because the CTO said so” is not enough. Good tickets explain what problem we’re solving, for whom, and why it matters. Dev brains need context to make smart decisions.

Make it work

Stick to what’s necessary to build and ship.

• Use bullet points, not paragraphs.

• Link your design files, architecture diagrams, and business proposals.

Make it fit your team

It can (and should) evolve. If your team is consistently skipping sections, that’s a signal that it needs fixing.

Let LLMs do what they do

One area where tools like ChatGPT absolutely excel is turning stream of conscience nonsense into something useful.

The process here is simple:

1. Provide ChatGPT/Gemini/whatever your desired template

2. Tell your tool what you need to get done

3. Let the tooling do the formatting

4. (Always) Edit for accuracy and content

Feature cards

Here’s the markdown I currently like for feature cards:

# Feature: [Clear and concise title goes here]

## Description
Brief overview of what’s being built, why it matters, and any helpful context.

- What is this?
- Who is it for?
- Why is it important?
- Any relevant background, links to old tickets, docs, or memes?


## Business Value / Goal
Why are we doing this? What business outcome are we supporting?

- Improves [user workflow / system performance / compliance]
- Helps launch [feature / product / marketing push]
- Solves [user pain / stakeholder concern / tech debt issue]
- Quantifiable impact if possible (e.g. saves X time, increases Y conversions)


## Definition of Done (DoD)
What *exactly* needs to be true before this ticket is considered complete?

- [ ] Code implemented and peer-reviewed
- [ ] Unit/integration tests written and passing
- [ ] Deployed to staging
- [ ] QA verified
- [ ] Documentation updated (user-facing and/or technical)
- [ ] Feature flagged (if needed)
- [ ] Approved by relevant stakeholders


## Testing Criteria
How do we confirm this actually works and doesn’t break the world?

- Test scenarios and edge cases
- Steps to manually test (if needed)
- Expectations for automation coverage
- Known limitations (if any)


## Design / Resources / Links
- [ ] [Design mockup](#)
- [ ] [Product spec](#)
- [ ] [API spec](#)
- [ ] [Related tickets](#)


## Dependencies / Blockers
- [ ] Depends on ticket ABC-123
- [ ] Needs final approval from [person/team]
- [ ] Blocked by [external system / legal / feature flag]

Example usage

Here’s an example of usage, using one of my side projects as an example.

Full disclosure: I am 100% info dumping here. Remember, my LLM tool is doing the formatting and structuring. I just need to get the thoughts out and provide the template. My typos are left as-is.

I need to develop a Jira feature for my storyboarding application. users should be able to add characters with attributes like age, occupation, education, motification, etc. we also need to support custom labels and custom key:value pairs because different character types (main, support, villain, etc) need different things to care about. we should also support custom images so that users can really “see” the characters. we should support one-off minor characters and characters that span many projects. critical for allowing users to define, refine, and reuse characters and their interactions. please write a feature card using this template: <copy and paste feature template>

Bug cards

Bug cards are easier, and a lot of is hopefully just copying the contents of an error from logs and adding some reproduction context.

The markdown:

# Bug: [Short, clear summary of the issue]

## Error / Overview
What’s happening, and why is it a problem? Include any user impact, severity, or urgency.

- Brief description of the bug
- Where it was discovered (prod, staging, specific environment)
- Error messages, screenshots, or logs (if available)

## Steps to Reproduce
Clear, step-by-step instructions so anyone can trigger the bug.

1. Go to [page / screen / feature]
2. Perform [specific action]
3. Observe [unexpected behavior]

**Expected Result:**  
What should happen if it worked correctly.

**Actual Result:**  
What actually happens (include error messages or weird UI behavior).

## Investigation Notes
Notes from debugging, QA, or dev triage.

- Initial theories about root cause
- Relevant commits, merges, or deployments
- Suspected affected components or services
- Logs, error IDs, or metrics
- Links to related tickets

## Impact
This section may be left blank to filled out by a PM or similar role.

- Affected users / percentage
- Business impact (revenue loss, blocked workflows, compliance risk)
- Urgency (critical, high, medium, low)

## Definition of Done (DoD)
- [ ] Root cause identified and fixed
- [ ] Unit / integration tests added or updated
- [ ] QA verified fix in staging
- [ ] Regression testing completed for related areas
- [ ] Deployed to production
- [ ] Monitoring / alerts updated (if applicable)
- [ ] Documentation updated (if needed)

## Testing Criteria
- Steps QA will use to verify the fix
- Any special data, users, or config needed
- Negative test cases to ensure no regressions


## References
- [Error logs](#)
- [Monitoring dashboard](#)
- [Related Jira tickets](#)
- [Slack discussion / incident doc](#)