Blog · 29 September 2026

Jira daily standup: run it from the board, ticket optional

A Jira daily standup works best when it is run straight from the board: open the sprint board, group it by assignee, and walk the columns from right to left so finished work is heard first and stuck work is heard last, where it gets the time. You do not need an app for that part. Where teams do need something extra is the paper trail around the meeting: a place for the notes, the blockers raised, and the follow-ups somebody promised. That is the one piece Jira does not create for you, and it is the piece this article spends its second half on.

The short answer #

• You want a better fifteen minutes? Configure the board once (swimlanes, quick filters, a blocked flag) and run the meeting from it. Free, native, covered in the first half below.
• You want a record of each standup in Jira? Create a daily standup ticket, and make sure it only appears on working days, because a ticket for a Saturday or a public holiday is noise somebody has to close.
• You want that ticket to arrive on its own? Use a schedule. Jira Automation can do it with a scheduled rule; Recurring Work Items for Jira can do it with a daily rule that skips weekends and your holidays.

Set up the board for a daily standup #

Every Jira Software board already has what a standup needs. The work is in turning the right settings on once, so nobody fiddles with the view while eight people wait.

1. Swimlanes by assignee. In the board settings, set swimlanes to Assignees. Each person's work now sits in one row, which is the order the meeting naturally takes.
2. A quick filter per question. Add quick filters such as Only my issues, Recently updated (a JQL like updated >= -1d) and Blocked (flagged is not EMPTY). Clicking one during the call is faster than searching.
3. Flag what is stuck. Agree that anything blocked gets Jira's flag before the meeting. The flagged card turns visibly different on the board, so blockers are seen without anyone having to remember to mention them.
4. Keep the columns honest. If "In review" holds cards nobody is reviewing, the standup is where that becomes visible. A column limit on the busiest column makes the pile-up impossible to miss.

How to run it: walk the board, not the people #

The classic format is three questions per person: what I did yesterday, what I will do today, what is in my way. It works, and it drifts into status reporting. Walking the board changes the question from "what did you do" to "what does this work need".

Right to left matters. Starting at "Done" and moving towards "To do" means the cards closest to shipping get discussed first, and the meeting ends on the cards that have not started, which usually need the least talk.

Whatever the format, keep two rules: problem solving happens after the standup, with only the people it involves, and anything promised in the room becomes a Jira item before the room empties. The second rule is where most teams lose the thread, and it is why the ticket below exists.

Do you need a daily standup ticket? #

Many teams do not, and that is fine. A daily ticket earns its place when one of these is true:

• The standup produces decisions or follow-ups that need a home you can search later. Notes in a chat thread scroll away; a comment on a dated issue does not.
• The team is distributed across time zones and some people post an asynchronous update instead of joining. A ticket per day gives everyone the same place to write it.
• Someone outside the team reads it. A manager, an auditor or a client who wants to see that the meeting happened and what came out of it.

If none of those apply, skip the ticket and just run the board. A daily ticket nobody writes in is worse than none, because it becomes a column of empty issues that people learn to ignore.

Three ways to get the ticket onto the board #

Create it by hand #

Somebody clones yesterday's standup ticket each morning and edits the date in the summary. It costs a minute, it needs no setup, and it stops the first morning that person is off sick. For a team trying the idea out for a sprint, this is the right place to start.

A Jira Automation scheduled rule #

Jira Automation's Scheduled trigger is Jira's own clock. Atlassian's trigger documentation (as of September 2026) describes it this way:

"You can run the flow at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules." Atlassian's Jira automation triggers documentation, as of September 2026

For a standup that means a cron expression for weekdays at a fixed time, followed by a Create work item action with a summary such as Standup {{now.format("yyyy-MM-dd")}}. The syntax and its traps are in Jira cron expression.

Two things to know before relying on it for a daily rule. The same page states that "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically", which for a daily rule is two working weeks of silence. And a cron expression knows weekdays but has no idea about your public holidays, so the ticket still appears on Christmas Day unless someone edits the rule. What a rule costs against your automation allowance is covered in Jira Automation pricing; one small rule a day is rarely the problem, the shared allowance behind it can be.

A recurring rule that knows your working days #

In Recurring Work Items for Jira, a project administrator sets the team's working week and holiday dates once in the project settings. A rule then runs every day and is told what to do when a day is not worked: skip it, move it to the next working day, move it back to the previous one, or ignore the calendar. For a standup, choose skip, and a weekend or a holiday simply produces no ticket.

A standup rule typically looks like this:

The last row is worth a sentence. A rule can be set to create nothing while the issue it created last time is still open. Close each standup ticket after the meeting and a new one appears tomorrow; forget, and you get one reminder sitting on the board instead of a stack of duplicates. The tokens reference lists every placeholder the summary and description accept.

Before saving, the editor previews the next five dates the rule will run, so a holiday you entered shows up as a gap in the preview rather than as a surprise on the day. After it runs, the rule's history names every day it created, skipped or failed, with the reason.

Side by side #

When the manual way is enough #

Stay manual, or skip the ticket entirely, if your team is co-located, the standup rarely produces follow-ups, and the board already answers "what is everyone doing". Plenty of good teams never create a standup ticket and lose nothing by it.

Stay with Jira Automation if you already have a set of scheduled rules you are comfortable maintaining, your team works the same five days every week, and a holiday ticket once in a while is not worth another app.

A scheduling app is worth it when the ticket must exist every working day without anyone thinking about it, when holidays matter, and when you have other recurring work in the same project: the weekly report, the sprint retrospective, the monthly maintenance. Those are covered in Jira weekly report, Jira retrospective template and Jira recurring tasks.

A standup checklist you can copy #

Paste this into the standup ticket's description, or into the board's working agreement:

1. Board open, swimlanes by assignee, blocked quick filter ready.
2. Walk right to left: Done, In review, In progress, To do.
3. Every flagged card gets an owner and a next step.
4. Anything longer than a minute goes to a follow-up after the call.
5. Every promise made in the room becomes a Jira item before people leave.
6. Close today's standup ticket.

The last step is the one that keeps tomorrow's board clean. Run the meeting from the board, keep the record in one dated ticket per working day, and let the schedule remember the part nobody should have to.