Part I: Jira, Azure DevOps, and Linear📋

You grep for PROJ-456 in the test suite. Three results. The ticket has seven acceptance criteria. Are the other four tested? You check Jira. The ticket was split last sprint. Two of the ACs moved to PROJ-512. Your grep missed them.

What They Are📋

Jira, Azure DevOps, and Linear are project management tools. Requirements live as tickets — epics, stories, tasks — with acceptance criteria written as bullet points in the description field. Teams track work through workflow states: To Do, In Progress, In Review, Done.

These tools are the backbone of software delivery. They're where PMs prioritize, where sprint planning happens, where stakeholders track progress. Nearly every professional team uses one.

How They Link Requirements to Tests📋

The most common pattern: developers reference ticket IDs in test names or comments.

// The developer manually puts the ticket ID in the test name
test('PROJ-456: admin can assign roles to users', async () => {
  const admin = await createUser({ role: 'admin' });
  const target = await createUser({ role: 'viewer' });
  await admin.assignRole(target, 'editor');
  expect(target.role).toBe('editor');
});

test('PROJ-456: role change takes effect immediately', async () => {
  // ...
});

test('PROJ-456: non-admin cannot assign roles', async () => {
  // ...
});

Some teams use Jira plugins (Xray, Zephyr for Jira) that add a "Test" issue type and link tests to stories via Jira's built-in linking system. Azure DevOps has "Test Plans" that associate test cases with work items. Linear has no native test integration.

More sophisticated setups use CI/CD webhooks to update Jira tickets when tests pass or fail.

What It Catches📋

Jira and its peers excel at workflow and visibility:

• PMs see what's planned, in progress, and done
• Sprint velocity is tracked automatically
• Dependencies between teams are visible
• Stakeholders get dashboards without reading code

For project management, these tools are irreplaceable. The problem is that teams also use them for requirement-test traceability — a job they're not built for.

Where It Breaks📋

The One-Way Link📋

The test knows about Jira (PROJ-456 in the test name). Jira doesn't know about the test. Unless you've invested in a plugin and keep it configured, the link is one-directional.

You can find tests for a ticket (grep the codebase). You cannot find tickets for a test (the test name is a string, not a queryable reference).

String-Based IDs📋

PROJ-456 is a string. Typos compile. Renames go unnoticed.

// Typo — compiles, runs, silently wrong
test('PROJ-465: admin can assign roles', async () => { ... });
//          ^^^ transposed digits — no one notices

// Ticket was renumbered after a project migration
test('PROJ-456: admin can assign roles', async () => { ... });
// PROJ-456 no longer exists — test still passes, link is dead

No tool will tell you that PROJ-465 doesn't match any ticket. The test passes. The link is broken. The traceability matrix is wrong.

Ticket Lifecycle vs. Test Lifecycle📋

Tickets move. They get split, merged, closed, reopened, moved to different projects. Each change can invalidate test references:

• Split: PROJ-456 becomes PROJ-456 (3 ACs) and PROJ-512 (4 ACs). Tests still reference the original.
• Moved: Project renamed from PROJ to PLAT. Every test reference is now wrong.
• Closed: Ticket marked Done and archived. Tests still reference it. Is that a problem? Nobody checks.
• Duplicated: Two tickets describe the same feature. Tests reference one. The other shows zero coverage.

No Completeness Check📋

Jira knows the ticket has 7 acceptance criteria (bullet points in the description). The test suite has 3 tests referencing PROJ-456. Are the other 4 ACs tested under a different ticket ID? Under no ID? Not tested at all?

Without a plugin, Jira cannot answer this question. With a plugin (Xray, Zephyr), you get a second source of truth that requires its own maintenance.

The Plugin Tax📋

Xray and Zephyr for Jira add test management capabilities: test issue types, test plans, coverage reports. They're well-built tools. But they create a second system:

• Test cases must be maintained in Jira AND in the codebase
• Someone must keep them in sync (or build automation to do it)
• The plugin's view of "coverage" depends on correct linking — which is still string-based
• License cost scales per user

You've traded one maintenance burden (mental model) for another (plugin administration).

How Typed Specs Differ📋

The core difference: in Jira, the requirement and the test are in different systems connected by strings. In typed specs, the requirement IS a type in the same codebase, and the test references it through the type system.

Honest Credit📋

Typed specifications do not replace Jira. They can't:

• Prioritize work across teams and sprints
• Track workflow states (To Do → In Progress → Done)
• Manage dependencies between teams or projects
• Provide stakeholder dashboards without requiring code access
• Handle non-code requirements (legal, compliance, operational)

Jira is a project management tool. Typed specs are a requirement-test traceability tool. They operate at different layers. The healthiest setup uses Jira for workflow and typed specs for verification — or generates typed spec features from Jira data (see Scaling Requirements as Code).

The question is not "Jira or typed specs?" It's "which layer does each one cover?"

Previous: Overview and Comparison Matrix Next: Part II: BDD Frameworks — the closest competitor to typed specifications.