How to Onboard to a New Azure DevOps Project Fast

You just got added to a new Azure DevOps project. Maybe you joined a new team. Maybe you got pulled into a cross-team initiative. Maybe someone left and you inherited a service you’ve never touched. Whatever the reason, you’re staring at an unfamiliar project and you need to get productive.

The temptation is to dive straight into the code. Don’t — not yet. Spend your first day building context, and you’ll write better code on day two than you would have on day five without it.

Here’s a practical checklist for getting oriented in a new Azure DevOps project.

1. Check the wiki and the README

Start with whatever documentation exists. In Azure DevOps, go to Repos > Wiki (if the project has one enabled) and skim through it. You’re not reading every page — you’re scanning for architecture diagrams, environment setup guides, deployment instructions, and any “start here” pages.

Then open the main repo and read the README. A good README tells you how to build, how to run tests, and what the project does. A missing or outdated README tells you something too — namely, that tribal knowledge is the primary documentation, and you should ask more questions in your first few days.

Don’t worry about absorbing everything. You’re building a mental map, not memorizing details. Knowing “there’s a page about the message queue architecture” is enough for now — you’ll come back to it when you need it.

2. Understand the board structure

Go to Project Settings > Boards > Project Configuration and look at the Area Paths and Iteration Paths. These reveal more about how the team works than almost anything else.

Area Paths tell you how the team divides its work. Are there paths for Frontend, Backend, Infrastructure? Or are they organized by feature — Payments, Auth, Notifications? This is the team’s mental model of their codebase, written in tree form.

Iteration Paths tell you the team’s cadence. Two-week sprints? Three-week? Are they using iterations at all, or is everything just sitting in the backlog? Check which process template the project uses — Scrum, Agile, or Basic — because it changes the available work item types and the meaning of the board columns.

This takes five minutes and saves you from asking obvious questions in your first standup.

3. Find the active work

Navigate to Boards > Sprints and look at the current sprint. This is the team’s “right now.” Who’s working on what? How many items are in progress versus done? Are there items that have been in progress suspiciously long?

Look at the sprint burndown if one exists. Is the team on track? Are they carrying over work from previous sprints? You don’t need to form opinions about this yet — you’re just absorbing context.

The Taskboard view is especially useful here. It shows you how work items break down into tasks and who’s responsible for each piece.

4. Scan the backlog

Open Boards > Backlogs and scroll through the top 20-30 items. These are the things the team considers most important (assuming the backlog is groomed — if it’s not, that’s also useful information).

Pay attention to the types of work. Is it mostly features? Bug fixes? Tech debt? A backlog full of bugs tells a different story than a backlog full of new feature epics. Look at the parent-child relationships too — Epics break into Features break into User Stories. This hierarchy shows you the team’s big-picture roadmap.

Don’t read every item in detail. Just scan titles and priorities. You’re getting a feel for what matters here.

5. Browse recent pull requests

Go to Repos > Pull Requests and filter by “Completed” to see recent merges. This is a goldmine of context that most people skip during onboarding.

PR history shows you:

• Coding patterns — how the team structures code, what frameworks they use, what tests look like
• Review culture — are reviews detailed or rubber-stamp approvals? How many reviewers per PR?
• Branch naming conventions — feature/, bugfix/, work item IDs in branch names, or just freeform?
• Key contributors — who’s doing most of the reviews? That person probably has the most context on the codebase

Read two or three PRs in full. Look at the diff, the comments, and how feedback gets addressed. You’ll learn more about the team’s engineering standards from three PRs than from any written coding guidelines.

6. Look at the pipelines

Navigate to Pipelines and look at the build and release configuration. Understanding how code gets deployed is critical context that’s easy to postpone and painful to not have.

Check:

• What triggers a build? Every push? Only PRs to main?
• How many stages does the release pipeline have? Dev, staging, production?
• Are there manual approval gates?
• How long does a build take? (This affects your daily workflow more than you’d think.)
• Is anything red or failing right now?

If the pipeline YAML is in the repo, read it. It’s often more accurate than any deployment documentation.

7. Find the shared queries

Under Boards > Queries, look at the Shared Queries folder. Teams create shared queries for the things they check regularly — active bugs, tech debt items, blocked work, items needing triage.

The shared queries are a window into what the team cares about tracking. A query called “Critical Bugs - Production” tells you the team has production issues worth monitoring. A query called “Parking Lot” tells you there’s a holding area for deprioritized ideas.

If there are no shared queries, that’s a signal too. The team might rely entirely on board views, or they might just not be heavy query users.

8. Read recent work items in full

Pick 3-5 recently completed work items and read the full thread — description, acceptance criteria, comments, linked PRs, state change history. Don’t skim; actually read the conversation.

This shows you how the team communicates. Do they write detailed acceptance criteria or just a one-line title? Do they discuss implementation in work item comments, or does all the conversation happen in Slack? Do they link PRs to work items? Do they update items when things change, or does the item description go stale immediately?

You’re calibrating your own behavior to match the team’s norms. If everyone writes detailed comments on work items, you should too. If nobody does, writing a novel in a task comment will just be noise.

Start building your personal context from day one

Here’s the thing about onboarding: you’re going to open dozens of work items in your first week. Bugs someone mentions in standup. Epics that get referenced in planning meetings. Items you stumble across while reading the backlog. Three days later, you’ll remember seeing something relevant but have no idea which item it was or which project it lived in.

This is where TicketHop pays off immediately. Install it on day one, and every work item you visit during onboarding gets automatically tracked — no clicks, no bookmarks, no manual logging. Just browse Azure DevOps like you normally would.

As you go through this checklist, use TicketHop’s private notes to capture your first impressions. Jot things like “this is the main feature epic,” “ask about this in standup,” “similar to the auth service at my old company,” or “this PR shows the testing pattern.” Those notes attach directly to the work item, so when you come back to it a week later, your context is right there.

Think of it as a personal onboarding journal that lives on the actual work items instead of in a separate doc you’ll never open again. Your visit history builds automatically, and your notes give that history meaning.

By the end of your first week, you’ll have a searchable record of every work item you explored, annotated with your own observations. That’s the kind of context that normally takes weeks to build and is almost impossible to reconstruct once it fades.

The goal: be dangerous by day three

You don’t need to understand everything about a new project on day one. You need to understand enough to ask good questions on day two and start contributing on day three.

This checklist gives you the structure for that. Wiki and README for the big picture. Board structure for how the team thinks. Active work for what’s happening now. Backlog for what’s coming. PRs for how code gets written. Pipelines for how it ships. Queries for what the team tracks. Work item threads for how they communicate.

Do this on your first day. You’ll walk into your first standup already knowing the names of the epics, the shape of the sprint, and who to ask about what.

Install TicketHop before you start — it’s free, takes two seconds, and turns your onboarding browsing into a personal knowledge base you’ll actually use.