nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rules of tasks naming

Julia Indyukova

Hi guys

Could you share your experience please

My colleagues and me are having a discussion about core rules of naming tasks in Jira. My experience is - to start with a verb but keep them short.

My colleagues insist on absence of any rules except for tasks except being short and understandable.

What do you think?

Accepted answers

All comments

Walter Buggenhout

Hi @Julia Indyukova,

Since it is all about entering free text in a tool, it is better to talk about working agreements rather than rules, imho.

But there are a couple of simple guidelines and best practices that can make your life easy (or difficult). Some examples:

First and foremost: if you work together with multiple people inside Jira, make sure that everybody understands what is expected to be done. So make sure to use the summary and description fields to clearly explain this.
The summary is what you see in Jira when you look at a list of tasks (in e.g. list view or All work). Using clear, descriptive titles there will help you avoid to open every single task's details to get what you are supposed to do.
There are different types of work that you can manage in Jira, obviously. We used to have a practice in place where we tried to write summaries differently depending on the type of work (and corresponding work type in Jira). A few examples:
- For stories, we used the traditional story format (As a user, I want to ... so I ...).
- For bugs, we had the habit to describe what was not working (tax calculation at the bottom of the xyz form shows invalid result)
- For a sales opportunity, we combined the customer name with the type of opportunity it was for. (e.g. Atlassian - Jira upgrade to 500 users)
- For tasks, we tried to summarise the desired end state (e.g. CEO Office is redecorated).

Keep in mind that not everyone in your organisation is a Shakespeare and/or as skilled writer. Having some guidelines and examples in place always helps to make it easier. But sticking to the principle that the better you define work inside the tool, the less time you lose to figure out afterwards what was actually intended might just be the most important thing to agree amongst you all.

Hope this helps!

Julia Indyukova

Thanks, but I'm mostly interested in naming but not in description.

Walter Buggenhout

Yes, @Julia Indyukova. All the examples I mentioned for work types are examples we used as naming principles for the summary field.

Julia Indyukova

Does summary = topic field in your case?

John Funk

Hi Julia,

As long as the summary is descriptive enough that people know what it means, that is sufficient for me. Statuses in the workflow, however, I prefer to be verbs.

Julia Indyukova

But you are talking about summary, not the topic field. I am talking about "topic".

"Тема" - on the pic.

Снимок экрана 2025-11-24 в 11.51.08.png

Rustem Shiriiazdanov _Actonic_

Hi @Julia Indyukova

In our Team we have a naming convention where we put affected Products Components names and then short description of what is to be done (verb + description). E.g. "URT | Pivotopia | Do Something". It allows us quickly (without any filters and clicks on the task itself) get the context of what a task is about (in example above it will be clear for the team that the task is about doing something with Pivotopia data processing library in URT component of the product we develop).

Screenshot 2025-11-24 103621.png

We have been using that kind of names for tasks for years now, and quite happy with that.

Regards,

Rustem

John Funk

Your original question was about naming tasks. That is what the Summary field does. What EXACTLY are you trying to accomplish? Please write in your own language if you feel more comfortable with that.

Rustem Shiriiazdanov _Actonic_

@Julia Indyukova I second @John Funk here, it looks like there could some confusion. I assume your Jira is running Russian translation, and according to the materials I found, the "Тема" in many cases is the same as "Summary", whereas in other cases it's "Epic" (see pictures below from some website I found)

It would be indeed appreciated if you could explain in details what you want to achieve.

Gabriela - LeanZero

I'm with Walter on this one, a working agreement tends to stick better than a hard rule, because the moment a convention feels like bureaucracy people quietly start gaming it. That said, a shared shape does pay off, and Rustem's 'Product | Component | Action' pattern is a good example of one, it gives you context straight from the board without opening the card.

The verb idea is nice but tricky to enforce, since 'starts with a verb' or 'is descriptive enough' isn't something a regex can judge, a regex can only match a fixed prefix or character pattern. So if you keep it as an agreement plus a solid issue template, you'll get most of the benefit without fighting the tooling.

If you ever did want to enforce the meaning of the convention rather than just its shape, that's about the one case where an app earns its keep, since native validators can't read intent. CogniRunner lets you write the rule in plain English and checks the summary against it on create or on a transition, so 'the summary starts with an action verb and names the component' becomes an actual gate. Full disclosure, I'm on the team that builds it at LeanZero, so treat it as one option rather than a nudge, the agreement-plus-template route is honestly fine for most teams.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-data-center

data-center