Tracking Work Across Multiple Azure DevOps Projects

If you work in Azure DevOps, there’s a good chance you don’t live in just one project. Maybe it’s the main product, an internal tools repo, and a shared component library. Maybe your team owns two microservices that happen to live in separate projects because someone made that call three years ago and nobody’s going to undo it now.

Whatever the reason, you’re bouncing between projects every day. And while ADO technically supports cross-project work, the experience has some sharp edges.

What ADO gives you out of the box

Azure DevOps does have features aimed at cross-project visibility. They’re worth knowing about, because some of them genuinely help.

The “My Work Items” hub. Navigate to the organization level (not a specific project) and you’ll find an “Assigned to me” view that pulls work items from every project in the org. It’s a flat list, sorted by recently updated, and it works. If all you need is “what’s assigned to me right now?” — this covers it.

Cross-project queries. In the Queries editor, you can toggle off the project scope and write a query that spans multiple projects. You can filter by project name, area path, iteration, or any standard field. The query results look the same as a single-project query — they just pull from a wider pool.

Favorites and recent items. You can pin projects, queries, and boards to your favorites for quicker access. Azure DevOps also tracks your recently visited items in the top nav. Between these two, you can reduce the number of clicks to get where you need to go.

Delivery Plans. If your teams use sprints, Delivery Plans give you a timeline view that can span multiple projects and teams. It’s more of a planning tool than a day-to-day tracker, but it’s useful for seeing how work aligns across teams.

Where it falls apart

The native features sound reasonable on paper. In practice, the friction compounds.

Cross-project queries are limited. You can query across projects, but you can’t use project-specific fields like custom area paths in a meaningful way across boundaries. If Project A uses area paths like Frontend/Components and Project B uses UI/Shared, your query can’t reason about the relationship between them. You’re filtering on strings, not structure.

Boards don’t span projects. Each board belongs to a single team in a single project. There’s no “show me a Kanban board of all my in-progress items across three projects.” You have to open each board separately, hold the state in your head, and mentally merge them.

Context evaporates when you switch. This is the one that really hurts. You’re looking at a bug in Project A, you hop to Project B to check on a related PR, and when you come back, you’ve lost your place. Browser tabs help, but only if you keep them open — and “just keep all the tabs open” is its own problem. Your recent items list in ADO rotates fast if you’re active across multiple projects, and there’s no way to say “pin this specific work item to the top.”

Organizations add another layer. Some companies split work across multiple ADO organizations — maybe one for internal tools and another for client-facing products, or separate orgs inherited from acquisitions. The “My Work Items” hub only works within a single organization. Cross-org queries don’t exist at all. You’re on your own.

The mental overhead is the real cost

The tooling gaps aren’t catastrophic individually. You can work around each one. The problem is that you have to — and every workaround costs a small amount of mental energy. Over a full day, that adds up.

You find yourself keeping a notepad (physical or digital) with work item IDs you need to get back to. You open the same query in multiple tabs. You bookmark specific items. You write notes in Slack messages to yourself. None of this is “work” — it’s overhead. It’s the tax you pay for being spread across projects.

Research on context switching shows that even small interruptions — like figuring out “which project was that bug in?” — carry a cognitive cost that accumulates throughout the day.

A different approach to cross-project tracking

This is one of the reasons we built TicketHop. It’s a Chrome extension that automatically tracks every Azure DevOps work item you visit, regardless of which project or organization it belongs to.

There’s no configuration per project. You don’t need to set up cross-project queries or bookmark anything. Just browse Azure DevOps the way you normally do — open a work item in Project A, check a task in Project B, review a bug in a completely different organization — and TicketHop records it all in a single, unified history.

Hit Ctrl+K (or Cmd+K on Mac) and your recent items are right there, across every project and org. Type # followed by a work item ID to jump directly to it. No hunting.

Custom lists are where it gets useful for cross-project work specifically. You can create a list called “Auth Migration” and drag in work items from three different projects. Or a list called “Waiting on Others” that groups items by status regardless of which board they live on. The organizational structure in ADO doesn’t have to match how you actually think about your work.

You can also attach private markdown notes to any work item — “blocked on API changes in Project B, see item #4821” — so when you come back to it tomorrow, you don’t need to reconstruct the context from scratch.

If you work across multiple machines, encrypted sync keeps everything available on every device with end-to-end encryption. Your notes, lists, and history travel with you.

You shouldn’t need a system just to remember what you were doing

ADO’s cross-project features are useful building blocks, but they don’t solve the fundamental problem: keeping a clear mental picture of your work when it’s scattered across projects. Queries give you snapshots. Favorites give you shortcuts. But neither gives you a running, automatic record of what you’ve touched and where you left off.

If you spend your days jumping between Azure DevOps projects and you’re tired of losing track of things, give TicketHop a try. It’s free to install and works in about two seconds — no setup, no permissions, no accounts required to get started.