On this page
EtaperoPublished:

Jira and the project plan: dates above the tracker

Jira answers “what is the team doing now” well. It answers a project manager’s questions less well: will we make the date, what is moving the release, which risks hang over a milestone. Issues are the bottom level of the work; project dates live a level above.

What a tracker lacks for managing dates

  • Dependencies between larger pieces of work. You can link issues in a tracker, but it usually doesn’t schedule from those links or show a critical path.
  • A baseline. Dates on issues get rewritten, and a month later it is unclear which date was promised.
  • Work outside the tracker. Procurement, approvals, certification, training — often not in Jira, yet they move dates just the same.
  • A portfolio. Management needs the picture across projects: goals, key risks and blockers on one page.

A working setup has two levels:

  1. The project plan — phases, work packages, milestones, dependencies and the baseline. The project manager owns it. See “The work breakdown structure”.
  2. Jira issues — the teams’ tasks, kept in the tracker they already use.

The link between the levels is a plan row pointing to an issue. The system compares the row’s status and assignee with the issue and, when they differ, offers to update the row. The plan then keeps up with what the team marked in Jira, without a separate report from the team.

Why the sync should be read-only

Two-way sync looks convenient but causes trouble:

  • the two systems start arguing over whose data is right;
  • changes in the tracker need sign-off from its owners and administrators;
  • a configuration mistake can change issues in bulk.

If the project management system only reads Jira, the tracker stays the single source of truth for tasks, and connecting it doesn’t require changing how teams work.

What a project manager should look at

  • Issues at risk: critical issues about to miss their deadline.
  • Open issues with links to the related tickets.
  • Gaps between plan and tracker: rows whose status or assignee differs from the linked issue.
  • Analytics on issue history: how long work takes from start to resolution, where tasks get stuck.

How to start

  1. Decide which issues belong to the project: by label or epic.
  2. Build the top level of the plan: phases and milestones.
  3. Link key plan work to issues.
  4. Record a baseline and check the variance once a week.

Where to do it

In Etapero a project’s issues come from Jira by label or epic. The sync only reads Jira: it sends nothing but sign-in, search and read requests. A plan row can be linked to an issue — the system offers to update its status and assignee from Jira; the Jira work page splits issues into sections by JQL or a Jira filter, and issue history feeds analytics widgets.

Jira is a trademark of Atlassian. Etapero is not affiliated with Atlassian.