i

Description

Nef d’un atelier d’entretien ferroviaire, avec sa fosse et ses rails, ses étagères et ses rangements alignés.

Source

Samuel Zeller samuelzeller · original page

Licence

CC0 Public domain

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

Azure DevOps Server (ex-TFS) in Depth

You will be able to describe the Server → collections → projects → teams organization, and what is shared or isolated at each level.

In brief

• You will be able to describe the Server → collections → projects → teams organization, and what is shared or isolated at each level.
• You will know how to choose and customize a process template (Agile, Scrum, CMMI, Basic, inherited process) without falling into pitfalls.
• You will master work items, states, links, area/iteration paths, backlogs, boards, capacity, WIQL queries, dashboards.
• You will know how to connect Power BI to work items (Analytics/OData), use the REST API, and plan a migration.
• Common thread: a SQL Server datamart fed by an SFA application, multilingual Power BI reports, versioned in TFVC, delivered as installation kits. For version control, see TFVC in Depth.

Rating context: team of 5 to 15 people, on-premise data/BI project; /5 ratings are assessments (see RATING).

On this page

1. 🟢 Novice — What is it, and what is it called today
   1. 🟢 A modern lifecycle
2. 🟢 Novice — Organization: collection, project, team
   1. How many projects should you create?
3. 🟢 Novice — Process templates and work item types
   1. 🟢 States, reasons, and rules
4. 🟡 Hands-on — Links between work items
   1. 🟡 Ticket ↔ TFVC changeset link
5. 🟡 Practice — Area paths and iteration paths
   1. Area paths: who owns what
   2. Iteration paths: when
   3. Conventions that avoid trouble
6. 🟡 Practice — Backlogs, boards, sprints, capacity
   1. The Kanban board
   2. Taskboard, capacity, burndown
   3. Tool limits for velocity
7. 🟡 Practice — WIQL queries
8. 🟡 Practice — Dashboards and widgets
9. 🔴 Expert — Analytics, OData, and Power BI on work items
   1. The three ways to consume it
   2. Recommended data model for a project report
   3. When to prefer direct SQL access
10. 🔴 Expert — REST API, extensions, and automation
    1. REST API
    2. Extensions
    3. Rules, hooks, and notifications
11. 🔴 Expert — Inherited process and customization pitfalls
    1. Customization pitfalls
12. 🔴 Expert — Test Plans and Pipelines, in two useful words for data projects
    1. Test Plans
    2. Pipelines
13. 🔴 Expert — Migration timeline and plan
    1. Typical on-premises version upgrade plan (to adapt)
14. 🔴 Expert — Structuring good practices
15. Metrics — tool rating
16. 🤖 AI contribution
17. See also

Level: 🟢→🔴

🟢 Novice — What is it, and what is it called today#

Team Foundation Server (TFS) is the former name of Microsoft's collaboration server (code, tickets, builds, tests). It was renamed Visual Studio Team Services (VSTS) on the cloud side, then Azure DevOps Services, and Azure DevOps Server on the on-premise side (starting with version 2019). The names coexist in people's minds and in paths: people still say “TFS.”

The features are grouped into services:

🟢 A modern lifecycle#

According to Microsoft announcements in late 2025, Azure DevOps Server is no longer year-based: the latest version (announced December 9, 2025) is delivered under the Modern Lifecycle Policy, without a year number or fixed end-of-support date as long as you stay current with updates and system prerequisites (status 2026-10, to be rechecked on the official lifecycle page before any upgrade decision). Practical consequence: you no longer choose “2022 vs 2025,” you commit to following updates, as with a service.

🟢 Novice — Organization: collection, project, team#

Azure DevOps Server
 └─ Project collection  (e.g. DefaultCollection)        ← 1 SQL database per collection
     ├─ Project “MyProduct”   (process: Agile/Scrum/CMMI/Basic)
     │    ├─ Team “Datamart”  (backlog, sprints, capacity, board)
     │    ├─ Team “Reports”
     │    └─ Team “Support”
     └─ Project “Internal tools”

• The server hosts one or more collections. A collection = an administration, backup, and upgrade unit = one SQL database (Tfs_<Collection>). A collection can be detached/attached (useful for migration, see below).
• The project (formerly “team project”) groups work items, repositories, pipelines, wiki. It applies a process template. Area paths and iteration paths form the organizational and planning tree.
• The team is a view: it selects area paths (what it owns) and iteration paths (its sprints), has a backlog, a board, capacity, dashboard widgets. A project can have multiple teams; a user can join several.

How many projects should you create?#

Expert rule: fewer projects, more teams. A project = a hard boundary (permissions, process, limited cross-project queries). One project per application multiplies admin overhead and makes cross-cutting reporting painful. Create a separate project only for: a confidentiality requirement, an incompatible process, or an independent lifecycle.

🟢 Novice — Process templates and work item types#

The process template determines work item types, their states, and fields.

Some major types:

• Epic: major initiative (multiple quarters). Feature: deliverable capability (a few sprints). Story / PBI / Requirement: value deliverable in one sprint. Task: technical action (hours). Bug: defect; it can be tracked as a story or as a task depending on team backlog configuration (team-level “bugs” setting). Issue / Impediment: blocker to remove. Test Case / Test Plan / Test Suite: Test Plans service types.

🟢 States, reasons, and rules#

Each type has its states (field System.State) and, for each transition, reasons (System.Reason). Rules (required fields by state, automatic values, read-only fields) accompany each transition. Example for an Agile process Bug: transition to Resolved → “Resolved Reason” field (Fixed, As Designed, Cannot Reproduce...); transition to Closed → verification by tester.

🟡 Hands-on — Links between work items#

Links are the tool's real value: they turn a list into a traceable graph.

🟡 Ticket ↔ TFVC changeset link#

In TFVC, check-in associates one or more work items: in Visual Studio (Team Explorer) by checking the item in “Related Work Items”; at the command line with tf checkin /associate:12345,12346 (syntax may vary by tf.exe version, verify with tf checkin /?). The “Work Items” check-in policy can make association mandatory: recommended for any repository that produces delivered kits.

# Check in while associating two tasks and a comment, in a TFVC environment
tf checkin /comment:"Added sector filter in DIM_CLIENT" /associate:12345,12346 /noprompt
# View work items associated with a changeset
tf changeset 45815

🟡 Practice — Area paths and iteration paths#

Area paths: who owns what#

A hierarchical tree (MonProduit\Datamart\Dimensions, MonProduit\Rapports\Rapport Standard…). It is used to: route items to the owning team, restrict access (permissions by area path), filter queries. A team “owns” one or more areas and, optionally, their sub-areas.

Iteration paths: when#

Planning tree (MonProduit\2026\Sprint 26-19). Each node has a start and end date. A team selects the iterations it uses (sprints visible in its backlog). Iterations are shared across the project but enabled per team.

Conventions that avoid trouble#

🟡 Practice — Backlogs, boards, sprints, capacity#

Azure DevOps provides, per team, several configurable backlog levels:

Visible levels are set in Team settings → Backlogs; bugs can be handled as stories, as tasks, or ignored in the backlog.

The Kanban board#

Columns = states, but you can split a column into Doing / Done (“Split columns”); WIP limits per column; swimlanes for expedite items; card rules (color based on a field or tag); Definition of Done criteria (checklist per column). The board respects backlog order (Stack Rank).

Taskboard, capacity, burndown#

The sprint relies on three screens:

1. Planning: drag and drop items from the backlog into the sprint; total estimate (points/hours) appears.
2. Capacity: per person, days off, activity (Development/Testing/Design…) and capacity per day (hours). Team holidays entered once. Overcommit indicator per person and per activity.
3. Taskboard: To Do / In Progress / Done columns for tasks; update of Remaining Work; sprint burndown calculated in remaining hours or tasks (depending on settings).

Tool limits for velocity#

The Velocity widget aggregates points per sprint but does not track historically scope changes during the sprint with the granularity of a dedicated tool; for reliable burnup, use Analytics (see below) or the “Sprint trend” feature. See Project Metrics and Reporting.

🟡 Practice — WIQL queries#

Saved queries are shareable filters (flat list, tree, or direct links). They rely on the WIQL language (Work Item Query Language), close to read-only SQL: SELECT … FROM WorkItems | WorkItemLinks WHERE … ORDER BY ….

-- Active team tasks in the current sprint
SELECT [System.Id], [System.Title], [System.AssignedTo], [Microsoft.VSTS.Scheduling.RemainingWork]
FROM WorkItems
WHERE [System.TeamProject] = @project
  AND [System.WorkItemType] = 'Task'
  AND [System.State] <> 'Done'
  AND [System.IterationPath] = @currentIteration
ORDER BY [System.AssignedTo], [System.Id]

-- Old bugs with no activity for 60 days (backlog health)
SELECT [System.Id], [System.Title], [System.ChangedDate]
FROM WorkItems
WHERE [System.WorkItemType] = 'Bug'
  AND [System.State] IN ('New','Active')
  AND [System.ChangedDate] < @today - 60
ORDER BY [System.ChangedDate]

-- Stories under a given feature, through hierarchical links
SELECT [System.Id] FROM WorkItemLinks
WHERE [Source].[System.Id] = 1234
  AND [System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward'
  AND [Target].[System.WorkItemType] <> ''
MODE (Recursive)

Useful macros: @Me, @Project, @Today, @CurrentIteration, @TeamAreas, @StartOfWeek. Operators: UNDER (for paths), IN, CONTAINS, WAS EVER (field history), EVER. WAS EVER is valuable for flow data (“items that have been Blocked”).

🟡 Practice — Dashboards and widgets#

A team dashboard brings together widgets: Sprint Burndown, Velocity, Cumulative Flow, Cycle Time, Lead Time, Query Results, Chart for Work Items (pie charts, bars by state/assignee), Test Results, Build History, Markdown. Two depths:

• query widgets (a chart based on a saved query): simple, instant, limited to snapshots of the current state;
• Analytics widgets (Velocity, Cycle Time, Lead Time, CFD, Burndown): historical, calculated from the snapshot table.

🔴 Expert — Analytics, OData, and Power BI on work items#

Analytics is the platform's reporting service: a read-only model fed from work items, with history (daily snapshots and revisions). Integrated into Azure DevOps Services; on Azure DevOps Server it is installed and enabled per collection (built in starting with version 2020; on 2019, extension to install — verify based on your version). It uses the search index and a dedicated schema in the collection database.

The three ways to consume it#

OData example: number of active bugs per iteration (server-side aggregation).

https://<serveur>/<collection>/<projet>/_odata/v4.0-preview/WorkItems?
  $apply=filter(WorkItemType eq 'Bug' and State ne 'Closed')/
         groupby((Iteration/IterationPath), aggregate($count as Total))

Minimal M (Power Query) example for an OData feed, Windows authentication:

let
    Source = OData.Feed(
        "https://<serveur>/<collection>/<projet>/_odata/v4.0-preview/WorkItemSnapshot?" &
        "$filter=DateValue ge 2026-01-01Z and WorkItemType eq 'User Story'" &
        "&$select=WorkItemId,Title,State,StoryPoints,DateValue,AreaSK,IterationSK" &
        "&$expand=Iteration($select=IterationPath,StartDate,EndDate)",
        null,
        [Implementation = "2.0"]
    )
in
    Source

Recommended data model for a project report#

Tables: WorkItemSnapshot (grain = item × day: flow fact), WorkItem (current dimension), Iteration, Area, User, Date (calendar). Star relationships; flow DAX measures:

Completed items =
CALCULATE ( DISTINCTCOUNT ( WorkItemSnapshot[WorkItemId] ),
            WorkItemSnapshot[State] = "Done" )

Average cycle time (days) =
AVERAGEX ( VALUES ( WorkItem[WorkItemId] ), CALCULATE ( MAX ( WorkItem[CycleTimeDays] ) ) )

WIP =
CALCULATE ( DISTINCTCOUNT ( WorkItemSnapshot[WorkItemId] ),
            WorkItemSnapshot[State] IN { "Active", "Committed" } )

The CycleTimeDays and LeadTimeDays fields are provided by Analytics. For formulas and interpretation, see 10 — Project Metrics and Reporting; for Power BI model design, see Cross-Cutting Power BI Good Practices.

When to prefer direct SQL access#

It is tempting to read the collection database (Tfs_<Collection>, tbl_WorkItem* views) in SQL. This is unsupported by Microsoft (internal schema, modified in each version). Use only the Analytics warehouse and documented views, and never write.

🔴 Expert — REST API, extensions, and automation#

REST API#

Root: https://<serveur>/<collection>/<projet>/_apis/…?api-version=<n>. API versions are tied to server version; choose the highest one supported by the target server. Some entry points:

# Read a work item (integrated Windows auth, on-premises server)
$uri = "https://tfs.exemple.local/tfs/DefaultCollection/MonProduit/_apis/wit/workitems/12345?`$expand=relations&api-version=7.0"
Invoke-RestMethod -Uri $uri -UseDefaultCredentials -Method Get

Some reflexes: never write directly to the database; use the API or the official tool; limit throughput (rate limits on Services; on Server, the limit is your infrastructure); paginate with $top and continuationToken.

Extensions#

Extensions add widgets, tabs, menu actions, pipeline tasks, and work item contributions. They are installed per collection (Server version) or per organization (Services). Writing an extension requires: a vss-extension.json manifest, JavaScript/TypeScript or a web page, and packaging with tfx extension create. For a simple need, prefer the REST API from a scheduled script (alerting, synchronization) over an extension.

Rules, hooks, and notifications#

• Process rules (no code): required fields, conditional values.
• Service hooks: trigger a webhook/Teams/Slack on creation or state change.
• Subscription notifications: should be rationalized—too much mail kills the signal.

🔴 Expert — Inherited process and customization pitfalls#

On recent Azure DevOps Server versions, there are two customization models:

# Export the “Bug” type from the project (XML)
witadmin exportwitd /collection:https://tfs.exemple.local/tfs/DefaultCollection /p:MonProduit /n:Bug /f:Bug.xml
# Reimport after modification
witadmin importwitd /collection:https://tfs.exemple.local/tfs/DefaultCollection /p:MonProduit /f:Bug.xml

Customization pitfalls#

🔴 Expert — Test Plans and Pipelines, in two useful words for data projects#

Test Plans#

A plan contains suites (static, query-based, requirement-based) of test cases (steps, expected results, parameters). Execution produces runs with screenshots, logs, and linked bugs. For a BI project, parameterized test cases are used for number acceptance testing: “for customer X and month M, total report sales = reference value ± tolerance.” The result of each execution is tracked (who, when, which kit version). See Acceptance testing and business validation.

Pipelines#

YAML pipelines (versioned with code, recommended) or classic pipelines (designer, legacy). For data projects: database project build steps (SSDT/sqlpackage), installation kit build, test script execution, artifact publishing, deployment to an acceptance testing environment. See CI/CD and CI/CD for data: foundations, datamarts, pipelines, and reports.

🔴 Expert — Migration timeline and plan#

Three paths, depending on constraints:

Typical on-premises version upgrade plan (to adapt)#

🔴 Expert — Structuring good practices#

1. A short hierarchy: Epic → Feature → Story → Task. Beyond that, no one can keep track.
2. Written definitions of ready and done in the project wiki, linked to the backlog.
3. One field, one decision: no field without a consumer.
4. Teams by value stream, not by technical layer (avoid “the database team” and “the reporting team” passing tickets back and forth).
5. Consistent title naming: action verb + object (“Calculate linear shelf space by sector”).
6. Systematically link tasks ↔ changesets, bugs ↔ stories, stories ↔ features; verify by query (“stories without parent,” “bugs without code link”).
7. Backlog hygiene: quarterly review; any item with no movement for 6 months is either closed or refined (see metrics — backlog health).
8. Document the model: a wiki page “How we use the tool” (types, states, fields, links, conventions), reviewed whenever someone new joins.
9. Separate data incidents from software bugs: dedicated types, dedicated SLAs.
10. Measure flow (lead time, cycle time) rather than counting logged hours.

Metrics — tool rating#

See the comparison in 12 — Comparison.

🤖 AI contribution#

Useful prompt: “Here is a story and the domain rules. Propose 5 quantified, testable acceptance criteria. State the assumptions you make.” Details in 11 — AI and tools.

See also#

• Project Planning and Tracking Tools: Overview · Jira In Depth and Alternatives · Project Metrics and Reporting · Comparison of Planning Tools
• TFVC In Depth · Git In Depth · Source Control for Data: SQL and Power BI
• Scrum in Practice · Planning and Estimation (matrix) · Glossary

✻ Written by Claude Sonnet 5.5