A good Jira comment is short, specific and addressed to someone. It says what changed or what you need, names the person who must act, and leaves the ticket easier to understand than it was before. Anything that becomes a decision gets moved into the description, and anything that is really a defect becomes its own issue.

That sounds obvious, yet most teams we talk to have tickets with 60 comments, three half-finished debates and no clear answer. This guide covers what to write, what to leave out, and how to run user acceptance testing (UAT) comments so that sign-off holds up later.

Wezardapp

Make UAT Issues Clearer in Jira

Wezard records UAT screen activity, transcribes issues in real time, and detects duplicate tickets before they reach your Jira backlog.

Visit Wezard

TL;DR

Comment when something changes, when you need an answer, or when you finish work. Skip “+1” and “any update?” comments.
Use @mentions so the right person is notified, and ask one clear question per mention.
Treat comments as temporary. Once a decision is made, copy it into the description.
Log defects found in UAT as separate Bug issues, not as comments on the parent story.
Make sign-off a formal, timestamped comment from the authorized business user.

What a Jira comment is actually for
When to comment, and when not to
Write comments that stand on their own
Use @mentions with a clear ask
Format for scanning
Keep comments from becoming the source of truth
Restrict visibility only when you have to
Comments in UAT: where discipline matters most
A comment checklist you can paste into your team wiki
Our perspective: comments are where duplicate and thin tickets start
Make your Jira comment conventions stick
Where Wezard fits
FAQ
Sources

What a Jira comment is actually for

Comments are the conversation layer of a ticket. The description holds the requirement, the acceptance criteria and the context. Comments hold the “why”, the questions and the status updates along the way.

Lullabot’s guide to Jira ticketing recommends using comments for conversational decision-making and status tracking, not as a replacement for documentation. That one distinction prevents most of the mess. If a reader needs a comment to understand what the ticket is, the description has failed. If a reader needs the description to understand what happened last Tuesday, a comment is missing.

A quick test before you post: would someone who joins the project next month need this? If yes, it probably belongs in the description or a linked document. If it is only useful this week, a comment is fine.

When to comment, and when not to

Comment when something changes

Post a comment when the ticket’s situation shifts in a way the fields do not show:

The scope or an assumption changed.
You are blocked, and you can say on what.
You finished your part and the next person needs to know what to check.
A test environment, data set or build number changed.
You need a decision or an input from a named person.

Don’t comment to add noise

Skip these:

“+1” and “me too.” Use the vote or watch features, or link the related issue, so the ticket stays readable.
“Any update?” Check the status and the activity feed first. If there is truly no movement, @mention the assignee with a specific question.
Long technical debates. Lullabot notes that teams often use comments for lengthy back-and-forth, and suggests moving those discussions to a document or meeting, then recording only the outcome in Jira.
Status that the workflow already shows. If the ticket moved to “In Review”, you do not need a comment saying so.

Write comments that stand on their own

Vague updates waste the next reader’s time. Lullabot’s example is useful: a status like “Finished the blog content type” tells nobody what was actually done, while a summary listing the specific fields and configurations completed does.

A reliable shape for an update comment:

Lead with the point. What is done, blocked or needed.
Give the specifics. Build number, environment, data used, screens affected.
State the next step and the owner. Who does what, and by when if it matters.

Compare two comments on the same ticket:

Tested, looks fine.

Tested the refund flow in the staging environment, build 4.12, with a partial refund on an order that has two line items. Totals and confirmation email match the acceptance criteria. Not yet tested: refunds on gift-card payments. @Priya, can you confirm whether that is in scope for this release?

The second one takes 30 seconds longer to write and saves a meeting.

Use @mentions with a clear ask

An @mention alerts the person you tag, so it is the quickest way to get something in front of the right reader. Atlassian’s documentation on watching, sharing and commenting on work items covers mentioning teammates directly in a comment.

A few habits make mentions work:

One person, one question. “@Marcus, does the discount apply before or after tax?” gets an answer. “@everyone thoughts?” does not.
Mention only who needs to act. Use watchers for people who just need to follow along.
Put the mention where it can be understood. Lead with the name, then the question, so the notification email makes sense on its own.
Close the loop. When the question is answered, say what you will do with the answer.

In UAT, mentions carry extra weight. A guide on Jira testing strategy notes that tagging the right person is a critical step in sign-off, because the business user must be alerted when a ticket’s status needs their decision.

Format for scanning

Jira comments support wiki-style formatting, including headings, bold and italic text, code blocks, and bulleted or numbered lists. Use it with restraint:

A numbered list for steps or a sequence of findings.
Bullets for a set of unrelated items.
A code block for error messages, API payloads or log lines, so they stay exact.
Bold for the one thing the reader must not miss, such as a blocker.

In Jira Cloud you can press M to jump straight to the comment field, a small shortcut mentioned in Atlassian’s support page. On long threads, use the permalink in the comment’s More actions menu to point a colleague to one specific comment, rather than telling them to scroll.

Keep comments from becoming the source of truth

This is the habit that separates tidy projects from archaeological digs. Comments capture the reasoning, but they are scattered across a thread and easy to miss. Once a decision is final, update the description or acceptance criteria and leave a short comment saying you did.

For example:

Decision from Thursday’s review: refunds on gift-card payments are out of scope for this release. I’ve updated the acceptance criteria above and moved the gift-card case to a follow-up ticket.

Without that step, a new tester or an auditor has to read every comment to work out what the real requirement is. Lullabot makes the same point: comments hold the conversation, and final outcomes belong in the ticket itself.

If you also plan to edit comments after the fact, know that the trail may be thinner than you expect. Atlassian has an open request noting that creating or editing a comment is not logged in the audit log, with an automation-based workaround. Check the current status of that request before relying on comment edits as evidence, and prefer adding a new comment over rewriting an old one when the record matters.

Restrict visibility only when you have to

Some comments should not be seen by everyone: legal questions, security findings, personnel matters. Jira lets you limit who sees certain comments. A University of Waterloo guide on Jira Service Management suggests defaulting to open collaboration and restricting only when necessary, so you avoid information silos. The same logic applies to software projects. If a UAT tester posts something sensitive, such as a screenshot with customer data, restrict it or move it out of the ticket entirely.

Comments in UAT: where discipline matters most

UAT testers are usually business users, not engineers. They are checking whether the software does what the business asked, and they often have little patience for tooling. That makes comment conventions more important, not less.

Give testers a plain-language standard

Guidance built on ITIL lifecycle practice says UAT testers should get a standard process with clear, plain-English steps. In practice, give them a comment template they can copy:

Test case: the ID or title.
Result: pass or fail.
What I did: two or three steps.
What I expected and what happened.
Attachment: screenshot or recording.

Log defects as issues, not comments

A failed test is not a conversation. It is a defect. Business analyst guidance recommends that once a defect appears in UAT, it is logged as a formal Bug issue with reproduction steps, expected results and a link to the original story, rather than left as a comment on the parent ticket.

The story’s comment can then be one line: “Failed on gift-card refunds, see the linked bug.” Developers get a properly structured defect, the story stays readable, and your reports count bugs correctly. If you need help writing the bug itself, our Jira bug report template and guide to Jira bug reporting for QA teams walk through it.

Make sign-off a formal comment

In the testing strategy document we reviewed, the business user adds a comment to the story once all tests pass, and that comment acts as the approval gate. A clean convention looks like this:

UAT APPROVED: Dana Lee, Finance Operations, 10/14/2026. All 12 test cases passed in staging build 4.12. No open defects.

The same source advises that in regulated environments, such as those under SOX or ISO 9001, verbal approvals should never be accepted and sign-off should be a timestamped comment from the authorized business user. If your organization is audited, confirm the exact requirements with your compliance or internal audit team, since they decide what counts as evidence for your controls. Our walkthrough on how to sign off on test cases after successful UAT covers the process in more detail.

A comment checklist you can paste into your team wiki

Situation	Do	Avoid
Status update	State what is done, with specifics	“Done” or “Working on it”
Need an answer	@mention one person with one question	Tagging the whole team
Decision reached	Update the description, then comment that you did	Leaving the answer buried in the thread
Test failure	Create a linked Bug with steps and evidence	Pasting the defect into the story’s comments
Duplicate request	Link the related issue or vote	Posting “+1”
Sign-off	Formal, timestamped comment by the approver	Chat messages or verbal approval
Sensitive detail	Restrict visibility or move it elsewhere	Posting customer data in an open thread

Our perspective: comments are where duplicate and thin tickets start

We build UAT software, so we see what happens when business users report problems in the middle of testing. They are not trying to write good tickets. They are trying to finish their test script. So they type “search is broken” into a comment, and someone else types “I see this too” below it.

Two problems follow. The first is context: a comment with no steps, no screenshot and no environment forces a developer or analyst to go back and ask. The second is duplication: three testers describe the same defect in three different words, and it lands in the backlog as three tickets.

Our view is that the fix belongs at the moment of capture, not in a cleanup meeting later. That is why Wezard records the screen, transcribes what the tester says as they say it, and checks for likely duplicates before a ticket reaches Jira or Azure DevOps. The tester explains the problem by talking, and the ticket arrives with the evidence attached. Comments then go back to doing what they are good at: questions, decisions and sign-off.

Whatever tool you use, the principle holds. Capture defects as structured issues with evidence, keep comments for conversation, and move decisions into the description. We go deeper on this in our posts on why context matters in bug reports and preventing duplicate Jira tickets at capture.

— Marketing

Make your Jira comment conventions stick

A convention nobody follows is just a document. A few ways to make it real:

Write it down on one page. Put the checklist above in your team wiki or a pinned Jira comment, and keep it short enough that people will read it.
Start with kickoff. For UAT, show business testers the comment template before testing begins, not after the first messy ticket.
Use workflow structure. Atlassian’s learning materials on Jira workflow best practices help you design statuses so people do not need to announce transitions in comments.
Tune notifications. Too many alerts train people to ignore mentions. Admins can review notification schemes so the mentions that matter stand out.
Review one ticket together. Take a real ticket with a messy thread, and rewrite it as a team: pull the decision into the description, split out the bug, and add a proper summary comment.

If you want a wider view of how Jira fits into UAT, our post on building a Jira UAT workflow without plugins is a good next read, and tracking software feedback status in Jira shows how to keep statuses honest.

Where Wezard fits

If your UAT testers still report problems by typing into Jira comments or sending emails, Wezard gives them a faster path. They record their screen, describe the issue out loud, and Wezard transcribes it in real time and flags likely duplicates before anything reaches your Jira, Azure DevOps or ServiceNow backlog. Plans are published on our pricing page: Starter is $25 per month, Team is $70 per month and Business is $160 per month, with Enterprise available without a published price. You can also see how teams use it on our UAT testing page.

FAQ

Should I comment or edit the description in Jira?

Edit the description when the requirement, scope or acceptance criteria change, because that is the source of truth. Comment to explain why it changed and to alert the people affected. Doing both takes a minute and keeps new readers from digging through threads.

How long should a Jira comment be?

Long enough to be understood without opening another tab, and no longer. For most updates that means two to five lines. If you are writing paragraphs, the content is probably a decision that belongs in the description or a discussion that belongs in a meeting.

Is a Jira comment valid UAT sign-off?

It can be, if your organization’s process says so. A timestamped comment by the authorized business user is the approach described for regulated environments, where verbal approval is not accepted. Ask your compliance or audit team what evidence your controls require.

Should UAT bugs go in comments or separate issues?

Separate issues. A Bug with steps, expected results and a link to the original story is the recommended practice. Leave a one-line pointer in the story’s comments so the connection is visible.

How do I get someone’s attention on a Jira ticket?

Type @ and their name in a comment, and ask a single, specific question. Jira notifies the person you mention. Avoid tagging groups unless everyone really needs to act.

TL;DR

Table of Contents

What a Jira comment is actually for