How to Find Azure DevOps Work Items You Visited Last Week

It’s Monday morning. Someone in standup asks you about a bug you looked at on Thursday — the one with the weird null reference in the payment service. You know you opened it. You commented on something nearby. But the ID? Gone. The title? Something about “payment” probably.

So you start the hunt.

The built-in options (and why they fall short)

Azure DevOps gives you a few ways to retrace your steps. They all work, to a degree. None of them answer the simple question: “Which work items did I look at last week?”

Recent activity

The Recent activity section on the project summary page is the first place most people look. It shows a feed of recently updated work items — new comments, state changes, field edits.

The problem: this is project-wide activity, not your activity. If you’re on a team of 15 people, you’re scrolling through everyone’s changes. A work item you quietly opened, read for two minutes, and closed without editing? It won’t show up here at all. Recent activity tracks modifications, not visits.

”My Work Items” hub and the Assigned to me query

The My Work Items hub under Boards shows items assigned to you, items you’re following, and items you’ve recently modified. It’s useful for the stuff actively on your plate, but it has the same blind spot: if you visited a work item that belongs to someone else — to review context, check a related bug, read acceptance criteria — it’s invisible.

The built-in Assigned to me query has the same limitation by definition. You can tweak it to use @Me with Changed By, but that still only captures items you edited, not items you read.

The @RecentlyUpdated macro

If you’re comfortable building WIQL queries, you can use the @RecentlyUpdated macro. It returns items that were modified within the last 30 days.

Two issues. First, it’s project-scoped and not filtered to you by default — you have to combine it with @Me in the right field, and even then it only catches items where you were the one making changes. Second, it requires you to set up and save the query in the first place. Most developers I’ve talked to have maybe one or two saved queries, and “things I recently touched” usually isn’t one of them.

Follows

Azure DevOps lets you follow individual work items. When you follow something, you get notifications on changes and it appears in your “Following” list. This is genuinely useful for long-running items you care about.

But following is manual — you have to click the follow button each time. Nobody follows every work item they open during a busy week. It’s an opt-in tracking system, which means it only captures what you remembered to track. That’s the opposite of what you need when you’re trying to recall something you’ve forgotten.

Browser history

This is the last resort, and it’s worse than you’d expect. Azure DevOps URLs look like this:

https://dev.azure.com/org/project/_workitems/edit/12847

Your browser history shows you a list of URLs and page titles. If you visited 30 work items last week across two projects, you’re scrolling through a wall of similar-looking links, mixed in with every other page you visited. There’s no filtering by project, no work item type icons, no way to distinguish a Bug from a User Story at a glance.

And if your organization uses Azure DevOps Server (the on-prem version), the URLs are even less readable.

What’s actually missing

The gap in all of these approaches is the same: Azure DevOps doesn’t track what you viewed, only what you changed.

This makes sense from a platform perspective. Tracking views at scale would be expensive, and it’s not what boards and queries are designed to do. But from a developer’s day-to-day perspective, it creates a real problem. Most of the work items you open in a given week aren’t ones you edit. You open them to read context, check linked items, review descriptions, or glance at the acceptance criteria before you start coding.

Those visits vanish. And when you need to find one again, you’re stuck running queries that can’t query for “things I looked at” or scrolling through browser history that doesn’t understand what a work item is.

Automatic visit history with TicketHop

This is the exact problem that TicketHop was built to solve. It’s a Chrome extension that silently records every Azure DevOps work item you open — no clicks, no manual step, no follow button. Just browse Azure DevOps the way you normally do.

Open the extension popup (or hit Ctrl+K / Cmd+K) and your recent work items are right there, sorted by when you last visited them. Each entry shows the work item ID, title, type, and project. Need last Thursday’s bug? Scroll down or search by keyword. It takes seconds instead of minutes.

A few things that make this more useful than a smarter browser history:

• It understands work items. You see Bug, User Story, Task, Epic — not raw URLs. Items are grouped by project and visually distinct.
• It works across Azure DevOps navigation. TicketHop is SPA-aware, so it captures visits whether you navigate through Boards, Backlogs, Sprint views, or direct links. No page reload required.
• You can add private notes. Click into any tracked item and attach markdown notes — “left off at failing test in UserService” or “waiting on API team response.” Your future self will thank you.
• Custom lists let you organize items by sprint, feature, or however your brain works. Drag and drop to reorder.
• Everything stays private. Your visit history and notes are stored locally in your browser. If you enable encrypted sync for multiple devices, it’s end-to-end encrypted with a zero-knowledge architecture.

The point isn’t to replace Azure DevOps queries or the boards you already use. It’s to fill the gap that the platform doesn’t cover: a searchable, automatic log of every work item you’ve actually looked at.

Stop hunting, start working

The next time someone asks “what was that work item you were looking at?” — you shouldn’t have to spend five minutes digging through browser history or building a query that still can’t find view-only visits.

TicketHop is free to install and works out of the box with no configuration. If you spend your days in Azure DevOps, give it a try — your Monday-morning self will appreciate it.