Blog ·
Jira for project managers: set it up, read it, and keep the rhythm
Jira for project managers comes down to three jobs. First, structure the project so the work is broken down the way you report on it. Second, read the right views, so you can answer "are we on track?" without asking five people. Third, keep the rhythm: the weekly status report, the risk review, the steering meeting prep and the stakeholder update. The first two are well covered by Atlassian's own guides. The third is where project managers spend their evenings, because Jira does nothing about it unless somebody creates a ticket. This guide covers all three, in the order you would set them up.
Statements about Jira's built-in features and plans are as of October 2026, from Atlassian's own pricing page and documentation.
What a project manager needs from Jira #
A developer opens Jira to see their next task. A project manager opens it to answer questions from other people. It helps to write those questions down before configuring anything, because each one maps to a piece of setup:
| Question you get asked | What answers it in Jira | Set up once as |
|---|---|---|
| What is the plan? | Epics on a timeline, with dates | Epics with start and due dates |
| Are we on track? | Done against due, per epic | A saved filter and a dashboard |
| What is blocked, and by whom? | Linked work items and a "Waiting" status | A workflow status and link types |
| What did we decide, and when? | A decision or risk work item with its history | A work type for risks and decisions |
| What changed since last week? | Items resolved and created in the last 7 days | Two saved filters |
| Did the routine reviews happen? | A resolved ticket per review, per cycle | Recurring tickets, covered below |
If a question has no row in your setup, you will answer it by chasing people. That is the job Jira is supposed to remove.
Structure the project before the first sprint #
Keep the hierarchy short. For most projects three levels are enough:
- Epics for deliverables a stakeholder would recognise: "Customer portal launch", "Data migration", "Training rollout". Give each a start date and a due date.
- Tasks or stories for the work inside each epic, sized so one person finishes one in a few days.
- Subtasks only where a task has fixed steps owned by different people. Our Jira subtask template guide compares ways to get the same subtasks every time.
Then add two things most projects skip:
- A work type for risks (or a label, if you cannot add work types). Each risk gets an owner, a likelihood and impact in its description, and a due date for the next review. A risk that lives in a spreadsheet is reviewed when someone remembers the spreadsheet.
- A "Waiting" status with the reason in a field or a label. One status, many reasons, so the board shows what is stuck without growing a column per blocker.
If you run several similar projects a year, set this up once and copy it. Jira project template walks through picking a template and filling it with the work every project of that kind needs, and Jira epic template covers what to put inside each epic.
The views a project manager reads every day #
Jira has more views than any one person needs. These four cover nearly everything:
| View | Read it for | How often |
|---|---|---|
| Board | What is moving and what is stuck right now | Daily |
| Timeline | Epics against dates, and where they overlap | Weekly, and before any date conversation |
| Saved filter of overdue items | What slipped, by owner | Daily |
| Dashboard | The one page you share with stakeholders | Weekly |
The timeline is where dependencies show. Atlassian's pricing page, as of October 2026, lists dependency management as single-project on the Free and Standard plans and cross-project on Premium and Enterprise, where advanced planning (Plans) also sits. If your project depends on another team's project, that line decides whether Jira can draw the dependency for you or whether you track it as a linked work item and a note.
Three filters worth saving on day one, with PROJ replaced by your project key:
- Overdue:
project = PROJ AND due < now() AND statusCategory != Done ORDER BY due ASC - Changed this week:
project = PROJ AND (resolved >= -7d OR created >= -7d) - Stuck:
project = PROJ AND status = Waiting ORDER BY updated ASC
Subscribe to the overdue filter so it arrives by email every Monday. You get the list before the stand-up, without opening Jira.
Run the meetings from the board #
Most of a project manager's calendar is meetings that Jira can feed. Each one has its own guide on this blog, so here is only the short version of how they connect:
- Daily stand-up: walk the board right to left, finishing work before starting it. See Jira daily standup.
- Sprint planning: pull from a backlog that was refined before the meeting. See Jira for sprint planning and what a groomed backlog looks like.
- Retrospective: one ticket per retro holding the actions, so they are visible on the board next sprint. See Jira retrospective template.
- Weekly report: built from the saved filters above. See Jira weekly report.
The meetings themselves are on your calendar. The preparation for them is not in Jira. That gap is the next section.
The project manager's routine nobody puts on the board #
Here is a typical cadence of work that belongs to the project manager, and that has to happen whether or not the project is busy:
| Routine | Typical cadence | What goes wrong without a ticket |
|---|---|---|
| Weekly status report | Every Friday | Written late on Monday, from memory |
| Risk and issue log review | Every two weeks | Risks stay "open" with no owner for months |
| Steering committee prep | Monthly, a few days before the meeting | Slides assembled the night before |
| Stakeholder update email | Monthly | Stakeholders find out about a slip from someone else |
| Budget and forecast check | Monthly, near month end | The overspend shows up at quarter end |
| Dependency check with other teams | Every two weeks | A blocking dependency is found on its due date |
| Lessons learned or milestone review | At each milestone | Never happens once the next phase starts |
Each item is small, and a project manager could argue it does not need a ticket. A routine with a ticket has an owner, a due date and a record that it was done. It also shows on the board, so when you are on leave the person covering for you sees the risk review is due instead of finding out at the steering meeting. And when a sponsor asks "how often did we review risks on this project?", a filter of resolved risk-review tickets answers in seconds.
How to create the recurring PM tickets #
There are three honest ways to get a ticket for each routine. The right one depends on how many routines you have and who will look after the rules.
| Clone by hand | Jira Automation scheduled rule | A scheduling app | |
|---|---|---|---|
| Who creates the ticket | You, every cycle | A rule | A rule in the project |
| "Last working day of the month" | You remember | Needs a cron expression and some logic | Chosen in a form |
| Holidays | You notice | Handled in the rule, if at all | Set once for the project |
| When you are away | Not created | Created on time | Created on time |
| If it stops working | You notice the gap | The rule can switch itself off | The run history records the failure |
| Cost | Your time | Counts toward your automation allowance | App licence |
Option 1: clone by hand #
Keep a template ticket for each routine with its checklist in the description, and clone it each cycle. It costs nothing, and for a project with two routines and a manager who never takes leave, it is enough. It fails in the busiest week of the project, which is the week the risk review matters most.
Option 2: a Jira Automation rule #
Jira Automation's Scheduled trigger can create a work item on a timer. Atlassian's trigger reference says you can "run the flow at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules." A Friday status report ticket is easy. "Three working days before the steering meeting" is not, because cron has no idea which days your team works; our Jira cron expression guide shows how far cron goes.
Two things from Atlassian's own pages, read in October 2026, are worth knowing before you build ten of these. The trigger reference says:
Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically.
And every run counts toward your plan's monthly automation allowance. Atlassian's usage page lists 150 steps per subscription on Free, 400 per user on Standard, 750 per user on Premium and 1,000 per user on Enterprise, pooled across your Atlassian apps. A handful of PM tickets is a small draw, but they share that budget with every other rule on the site. Jira Automation pricing goes through the arithmetic.
Option 3: a scheduling app #
Recurring Work Items for Jira is our app, and routine tickets like these are the job it was built for. Each routine becomes a rule in your project:
- Turn the app on for the project and choose who may schedule: everyone, project administrators, or a named list of people and groups.
- Set the working week and add public holidays, so a rule can move off a day nobody is working.
- Create a rule per routine. Schedules can be every N days, chosen weekdays every N weeks, a day of the month every N months, or a position such as the second Tuesday or the last Friday of the month.
- Give each ticket its own name with tokens, for example
Status report, week of {{now.date}}orSteering prep {{now.monthName}} {{now.year}}. - Put the checklist in the description or as subtasks, and set the assignee, labels and a due date as an offset from the run.
It uses no Jira Automation allowance, because the scheduling is the app's own. Every run is recorded in the rule's history as created, skipped or failed, with the reason, and the next five occurrences are previewed before you save. A rule only ever creates tickets in the project it lives in. It is free for up to 10 users.
A starter set of rules for a project manager #
Adjust the cadence to your project's governance, then create these in the first week:
- Weekly status report, every Friday, due the same day. Description: the three saved filters to read, the sections of the report, and who receives it.
- Risk and issue review, every second Wednesday, due Thursday. Description: the risk filter, the rule "every open risk has an owner and a next-review date", and where decisions are recorded.
- Steering committee prep, on the last Friday of each month (or a few days before the meeting date), with subtasks for the timeline snapshot, the budget figure and the decisions needed.
- Monthly stakeholder update, on the first working Monday of the month.
- Budget and forecast check, on the 25th of each month, assigned to whoever owns the numbers.
- Dependency check, every two weeks, with the linked items filter in the description.
Add a pm-routine label to every rule. Then one filter, project = PROJ AND labels = pm-routine AND due < now() AND statusCategory != Done, tells you which part of your own job has slipped. If you want the steps inside each ticket to be checkable, see where checklist steps should live.
When the manual way is enough #
Not every project needs scheduled tickets. If the project is short, the routines are few and you never hand the project over, a calendar reminder and a cloned ticket are enough. If your site already runs Jira Automation comfortably inside its allowance, a Scheduled rule for the Friday report is a sensible first step. A scheduling app earns its place when you run several projects with the same cadence, when holidays and "last working day" keep producing tickets on the wrong day, or when you need proof that each review happened.
For a wider look at the options for repeating work, see Jira recurring tasks and Jira reminder.
Frequently asked questions #
Is Jira good for project managers? Yes, when the project is set up around the questions you get asked: epics with dates for the plan, saved filters for progress and slips, and a dashboard for stakeholders. It is weaker at the project manager's own routine, which needs recurring tickets of some kind.
Can Jira track risks? Jira has no dedicated risk register, but a risk work type (or a label) with an owner, a description of likelihood and impact, and a due date for the next review works well, and a filter turns it into a register you can share.
How do I get a status report ticket every week? Clone one by hand, create a Jira Automation rule with the Scheduled trigger, or create a weekly rule in Recurring Work Items for Jira with the title, checklist and due date filled in.