i

Description

Plan d’aménagement d’une ville côtière tracé à l’encre, avec ses avenues et ses quartiers.

Source

BJGunnaban · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Project Planning and Tracking Tools: Overview

You will be able to place the major tool families (ticket tracking, Kanban boards, portfolio management, code-integrated suites) and what each one actually does.

In brief

• You will be able to place the major tool families (ticket tracking, Kanban boards, portfolio management, code-integrated suites) and what each one actually does.
• You will be able to list the essential functions for Scrum (ordered backlog, sprint, capacity, burndown, WIP limit) and verify that a tool supports them without workarounds.
• You will have weighted selection criteria and a method for deciding without giving in to trends.
• You will know what changes for a data/BI project (non-codable items, acceptance testing on figures, delivery kits).
• Detailed pages: Azure DevOps / TFS, Jira In Depth and Alternatives, Project Metrics and Reporting, AI, rated comparison.

The /5 ratings in this guide are expert, contextual assessments (team of 5 to 15 people, data/BI project with a SQL Server datamart fed by an SFA field app, Power BI reports, TFVC version control). See RATING.

On this page

1. 🟢 Novice — What a planning tool is for
   1. 🟢 The five tool families
2. 🟢 Novice — Essential functions for Scrum
3. 🟡 Practical — Tool Landscape
   1. Azure DevOps Boards (and TFS, Azure DevOps Server)
   2. Jira (Software, Work Management, Service Management)
   3. GitLab (Issues, Boards, Epics, Iterations)
   4. GitHub Projects (+ Issues)
   5. Linear
   6. Trello, Asana, Monday
   7. Notion
   8. YouTrack, Redmine, Taiga
   9. Rally (Broadcom), Jira Align, Planview: scale
   10. Azure DevOps vs Jira in one table
4. 🟡 Practical — Selection Criteria
5. 🟡 Practical — Scrum Functions in Detail: What Separates the Tools
   1. Backlog
   2. Sprint and capacity
   3. Burndown, burnup, cumulative flow
   4. WIP
6. 🔴 Expert — Data model, hidden costs, and portability
   1. What a tool imposes without saying so
   2. Total cost of ownership (TCO)
   3. Reversibility and lock-in
   4. Dependencies in a data/BI project
7. 🔴 Expert — Five-step decision method
8. See also

Level: 🟢→🔴

🟢 Novice — What a planning tool is for#

A planning tool is not the project: it is the shared and visible memory of work to do, in progress, and completed. It answers four questions the team asks every day: what (content), who (ownership), when (order and dates), and where are we now (status). A spreadsheet can play this role for three people over one month; beyond that, you need history, links between items, permissions, notifications, and reports.

Minimum vocabulary (see the Glossary):

🟢 The five tool families#

1. Ticket tracking for software teams: Azure DevOps Boards (ex-TFS), Jira, YouTrack, Redmine, Taiga. Strong in workflows, queries, history, code integration.
2. Tools integrated into the code forge: GitHub Projects, GitLab Issues/Boards. The ticket lives next to the repository, merge requests, and pipeline.
3. “Modern” tools focused on speed and simplicity: Linear, Shortcut. Few settings, strong opinion, excellent UX.
4. General-purpose collaborative boards: Trello, Asana, Monday, Notion, ClickUp. Weak in process rigor, strong in adoption outside technical teams.
5. Portfolio management and scaled agility: Jira Align, Rally (Broadcom), Planview, ADO Portfolio. For strategy → team alignment and cross-team dependencies.

🟢 Novice — Essential functions for Scrum#

Before comparing logos, let's check what Scrum actually requires (framework, practice).

For the underlying estimation and velocity concepts, see Project Metrics and Reporting and the matrix topic Planning and Estimation (PLA).

🟡 Practical — Tool Landscape#

The descriptions below are those of a practitioner (as of 2026-10). Features change quickly; models (what the tool treats as a first-class object) change little and are what matter.

Azure DevOps Boards (and TFS, Azure DevOps Server)#

Model: typed work items, dependent on the process template (Agile, Scrum, CMMI); parent-child hierarchy; area paths and iteration paths; backlogs, boards, sprints, capacity; WIQL queries; native links to TFVC changesets, commits, builds, releases. Available in SaaS (Azure DevOps Services) and on-premises (Azure DevOps Server, successor to TFS). Strengths: code/CI/test integration in a single product, customizable process without marketplace, low cost if Visual Studio licenses are already in place. Weaknesses: thinner third-party ecosystem than Jira, dated UX, Microsoft roadmap more oriented toward GitHub. Details: dedicated page.

Jira (Software, Work Management, Service Management)#

Model: issues + workflows + schemes (types, fields, screens, permissions, notifications); Scrum/Kanban boards; JQL; Advanced Roadmaps / Plans; very rich Marketplace. SaaS (Cloud); the Data Center offering has an announced end of life on March 28, 2029 (Atlassian announcement of September 8, 2025; sales to new customers stopped as of March 30, 2026; existing customers can still buy new subscriptions, apps, and extensions until March 30, 2028 — as of 2026-10). Strengths: flexibility, ecosystem, market standard. Weaknesses: customization drift, per-seat cost, performance on high volumes. Details: Jira In Depth and Alternatives.

GitLab (Issues, Boards, Epics, Iterations)#

Model: issues linked to merge requests and pipelines; epics and iterations on paid offerings; self-hosted or SaaS. Strength: single platform from planning to deployment; weakness: planning is simpler than Jira or Azure DevOps (less rich fields, workflows, and reporting), some features are reserved for paid tiers.

GitHub Projects (+ Issues)#

Model: board/table/roadmap view-oriented over issues and PRs; custom fields; automations. Strength: natural adoption when code is on GitHub, integration with AI coding agents; weakness: few native Scrum concepts (iterations and burn-up-style Insights charts, but no capacity entry or dedicated burndown), modest governance and reporting.

Linear#

Model: issues, cycles (sprints), projects, initiatives; very fast, highly opinionated (little configuration); Free/Basic/Business/Enterprise tiers; AI agent platform and “Linear Agent” from the free offering onward, with some AI features running on credits (as of 2026-10, based on the pricing page). Strength: UX, product team velocity; weakness: poorly suited to regulated processes, heavy customization, and on-premises (SaaS only).

Trello, Asana, Monday#

Simple card boards (Trello), general-purpose work management (Asana), no-code management platforms (Monday). Strengths: lightning-fast adoption, non-technical users, clients and business teams. Weaknesses for Scrum: no rigorous sprint model, rudimentary capacity/burndown or via add-ons. Excellent for business acceptance testing tracking or a request board, rarely for the core of a technical backlog.

Notion#

Relational databases + pages: you can model a backlog, sprints, documentation, all in one tool. Strength: doc + tracking unification, flexibility. Weakness: no transactional workflow, weak governance and auditing, performance on high volumes, dependence on team conventions that erode over time.

YouTrack, Redmine, Taiga#

• YouTrack (JetBrains): highly flexible ticket tracking (scripted workflows, quick-entry commands), self-hosted or cloud, attractive pricing for small teams.
• Redmine: open-source, mature, self-hosted, highly modular through plug-ins; dated interface, agile support via extensions. A classic choice for small organizations and public administration.
• Taiga: open-source, highly visual agility (Scrum/Kanban), smaller community; check project vitality before committing.

Rally (Broadcom), Jira Align, Planview: scale#

For 10+ teams, SAFe/LeSS, or portfolio: release trains, increment objectives, dependencies, multi-team capacity. High cost and complexity; relevant only if coordination is truly the bottleneck, not to “look serious.” See Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…).

Azure DevOps vs Jira in one table#

🟡 Practical — Selection Criteria#

You do not choose “the best tool” but the least bad tool for a given context. Weight the criteria (total 100) before evaluating, otherwise the sales demo decides for you.

🟡 Practical — Scrum Functions in Detail: What Separates the Tools#

Backlog#

The major difference: is the backlog a view over a global order field (Azure DevOps: Stack Rank/Backlog Priority, Jira: rank) or a manually sorted board per view? A global order field allows multiple teams to align on “the same list”; local ordering by view produces invisible divergences.

Sprint and capacity#

Capacity is calculated as follows (formula used by the tool or to reproduce manually):

Sprint capacity (h) = Σ_people (sprint workdays − vacation − holidays) × productive_hours_per_day
Productive hours/day ≈ 4 to 6 out of 8 (meetings, support, unforeseen work) — order of magnitude, to be calibrated
Capacity in points ≈ average velocity of the last 3 to 5 sprints × (current capacity / past average capacity)

Azure DevOps offers capacity entry by person and by activity (Development, Testing, Design…) and shows an over-commitment indicator; Jira gets this through apps or Advanced Roadmaps plans; Linear, GitHub Projects do not make this a core function.

Burndown, burnup, cumulative flow#

See Project Metrics and Reporting: the critical point is whether the tool tracks scope (burnup) in addition to remaining work (burndown), because scope moves.

WIP#

WIP limits are native in Azure DevOps and Jira Kanban boards (to be verified for other tools, including Linear), but never enforcing: they alert. It is a behavior lever, not a technical lock.

🔴 Expert — Data model, hidden costs, and portability#

What a tool imposes without saying so#

• The estimation model: Azure DevOps stores Story Points (Agile/Scrum) or Effort (Scrum) and Remaining Work in hours; Jira: Story Points or Original Estimate field; moving these from one tool to another requires a mapping table.
• Status history: essential for calculating lead time and cycle time (metrics). A tool that does not track transitions makes these measurements impossible, or approximate.
• The link model: a single “parent-child” link constrains the hierarchy; a free “related” link opens the door to chaos. The ticket ↔ changeset/commit link is the key to regulatory traceability and auditing.

Total cost of ownership (TCO)#

Comparing only the per-seat price is a mistake. Line by line, over a 3-year horizon:

Reversibility and lock-in#

Dependencies in a data/BI project#

A datamart and reporting project includes elements that tools designed for software handle poorly:

See also Scrum and Data for adapting ceremonies.

🔴 Expert — Five-step decision method#

1. Frame the real need: size, constraints (on-premise, sovereignty, audit), flow (Scrum, Kanban, hybrid). Write 10 usage “stories.”
2. Weight the criteria before any demo (table above).
3. Shortlist 2 or 3 tools, never 6; eliminate based on hard constraints (on-premise, export rights).
4. 2-to-4-week pilot with a volunteer team, using a real dataset (50 to 100 migrated items).
5. Decide and plan the exit: cutover date, freeze the old tool to read-only, archiving plan.

See also#

• Azure DevOps Server (ex-TFS) in Depth · Jira In Depth and Alternatives · Rated comparison
• Overview of Version Control Systems · TFVC in Depth
• Scrum in Practice · Pitfalls and good practices in project management (cross-functional summary)
• Governance and Steering (matrix) · Glossary

✻ Written by Claude Sonnet 5.5