Time Tracking in Azure DevOps: The Complete Guide

Azure DevOps is built to track work — not time. It knows which tasks exist, who owns them, and what state they're in. What it doesn't know is who spent three hours on a bug last Tuesday, whether that time was billable, or whether anyone approved it.

If you've searched for "does Azure DevOps have built-in time tracking," the short answer is: partially, and probably not in the way you mean. This guide covers exactly what Azure DevOps offers natively, what teams typically need beyond that, the three realistic ways to track time in Azure DevOps, and how to pick between them.

Does Azure DevOps have built-in time tracking?

Azure DevOps has effort fields, not time tracking. Depending on your process template, work items carry a small set of numeric fields for estimating and burning down work:

• Original Estimate — the initial guess at how many hours a task will take (Agile and CMMI process templates).
• Remaining Work — hours left to complete the task. This is the field sprint burndown charts consume.
• Completed Work — hours spent so far (Agile and CMMI; the Scrum template's tasks only carry Remaining Work by default).

There's also sprint capacity planning: per person, per sprint, you can set available hours per day and days off, and Azure DevOps compares planned work against that capacity. Useful — but it's a planning tool. It models what people could do, not what they actually did.

What the effort fields actually store

Here's the detail that catches most teams: these fields are single scalar values, not entry logs.

When a developer updates Completed Work from 6 to 9, the field now reads 9. There is no record that says "3 hours, added Thursday, by this person, on this activity." The old value survives in the work item's revision history, but a revision timestamp records when the field was edited, not when the work happened — and revisions were never designed to be queried as timesheet entries.

Concretely, that means the native fields have no concept of:

• A time entry. No date, no duration-per-day, no person attached to a specific chunk of hours.
• Multiple people on one task. One Completed Work field per work item; two contributors' hours blur into a single number.
• Timesheets. There is no view where a person sees their week and fills in hours across work items.
• Approvals. Nobody signs off on anything, because there's nothing granular to sign off on.
• Billable vs. non-billable. No flag, no rates, no client dimension.
• Timers. Nothing to start when you begin work and stop when you're interrupted.

You can add custom numeric fields through an inherited process, but they inherit the same limitation: scalars that overwrite, not entries that accumulate.

None of this is a flaw. Azure DevOps' effort fields exist to power burndown and capacity math inside a sprint, and they do that job fine. They just were never meant to answer "who spent what, on which day, for which client."

What teams actually need from time tracking

Whether you're an agency billing clients, a consultancy invoicing by the hour, an internal team doing cost allocation, or an R&D group claiming tax credits, the requirements converge on the same list:

• Per-person, per-day entries. Hours attached to a specific person, date, and work item — the atomic unit every downstream process depends on.
• Timesheets. A weekly view where each person can see, fill, and submit their hours in minutes, not in a scavenger hunt across work items.
• Low-friction capture. Timers for people who like them, fast manual entry for people who don't. If logging time takes effort, the data decays within a sprint or two.
• Approvals. A lead or PM reviews and signs off before hours flow into an invoice or a report. Unapproved time is unbilled time — or worse, disputed time.
• Billable classification. Which hours are billable, to which project or client, ideally with some way to sanity-check the entries before they hit an invoice.
• Reporting people can actually use. Pivot by person, project, sprint, or work item type; export it; hand it to finance — without anyone writing queries or wrangling raw data.
• Data that stays with the work. The closer time entries live to the work items themselves, the more accurate they are and the less double-entry your team does.

Measure any approach against this list and the trade-offs become obvious.

How to track time in Azure DevOps: three approaches

There are three realistic ways to track time in Azure DevOps. Each one is legitimate at a certain team size and billing model.

Option 1: Use the built-in effort fields

The zero-cost, zero-setup option. The team agrees on a discipline: every time you work on a task, update Completed Work (add your hours to the current value) and decrement Remaining Work.

Where it works: small teams that only need sprint burndown to be roughly honest, with no billing, no approvals, and no per-day reporting.

Where it breaks:

• The math is manual and error-prone ("it said 6, I did 3 more, so… 9"), and every update silently destroys the breakdown of who did what and when.
• Multi-person tasks produce one blended number.
• The moment anyone asks "how many hours did we spend on Project X in March, by person?" you're reconstructing history from work item revisions — hours of effort for an approximate answer.

Option 2: Track time outside Azure DevOps

Spreadsheets, or a standalone time tracker that has no connection to your work items. Everyone logs hours in a second system, and someone reconciles it with Azure DevOps at invoicing time.

Where it works: very small teams, or organizations where the time system is mandated company-wide and engineering has no say.

Where it breaks:

• Double entry. Every engineer maintains the same reality in two tools. Context-switching tax on every single work session.
• Drift. Work item IDs get typo'd or skipped, projects get renamed in one system but not the other, and the two sources of truth diverge a little more each week.
• Adoption. Developers live in Azure DevOps. A tracker that lives somewhere else is a tracker that gets filled in from memory on Friday afternoon — which is not data, it's fiction with decimals.

Option 3: A time tracking extension inside Azure DevOps

Azure DevOps supports marketplace extensions that add first-class time tracking where the work already happens: a hub in your project navigation, plus time controls on the work item form itself. Entries become real objects — person, date, duration, work item — instead of a scalar field.

Where it works: any team that needs timesheets, approvals, billable hours, or reporting, and wants engineers to log time without leaving their workflow.

What to check before adopting one: covered in the next section — capabilities vary widely.

Side-by-side comparison

How to choose

A short decision path:

1. No billing, no reporting needs, burndown is enough? Stay on the native fields. Genuinely fine. Revisit when someone asks for a per-project hours report and you feel your stomach drop.
2. Company mandates an external system? Minimize the pain: standardize how work item IDs are referenced, and accept the reconciliation cost as a known tax.
3. You need timesheets, approvals, or billable hours? Use an extension. Then evaluate candidates on these criteria:

• Entry model. Real time entries (person + date + duration + work item), not decorated scalar fields.
• Capture friction. Timers and fast manual entry, available on the work item form — not just in a separate hub.
• Approval workflow. Submit, review, approve — with a clear state, not a convention.
• Reporting without a query language. If producing a per-client monthly report requires writing code or learning a query syntax, the reports will be produced exactly once.
• Migration path. If you're already using another time tracker, can you bring your history with you, or does year one start with an empty database?
• Procurement. Buying through the Microsoft commercial marketplace means it lands on your existing Microsoft invoice — one less vendor for finance to onboard.

How Hourdeck handles time tracking in Azure DevOps

Hourdeck — Time Tracking & Timesheets for Azure DevOps was built against exactly the checklist above. Everything happens inside Azure DevOps: an extension hub for timesheets, approvals, and reporting, plus a Time tab on every work item so logging hours never means switching tools.

What that looks like in practice:

• One-click timers and weekly timesheets. Start a timer from the work item you're on, or fill your week in a single timesheet view. Both write real time entries — person, date, duration, work item.
• AI drafts your week. Hourdeck reads your own commits, comments, and work-item activity and proposes a draft timesheet for the week. You review, adjust, and confirm — the Friday-afternoon memory reconstruction problem, deleted.
• Approvals built in. Team members submit timesheets; leads review and approve before hours go anywhere that matters.
• Evidence-aware billability checks. Because Hourdeck can see the activity trail behind your entries, it helps you verify that billable hours are backed by actual work signals before they reach an invoice.
• Point-and-click pivot reporting. Group and slice hours by person, project, sprint, or work item — in a report UI, not a query language.
• One-click history import. Already tracking time in another time tracker? Bring your history across in one step, so reporting continuity survives the switch.

Hourdeck is distributed as an Azure DevOps extension on the Visual Studio Marketplace and sold as a transactable SaaS through the Microsoft commercial marketplace — so purchasing goes through the Microsoft billing relationship your organization already has.

Try it on your own backlog

The honest way to evaluate any of this is with your team's real work items, not a demo project. Hourdeck is free for up to 3 users — no trial clock, no card — and paid Team and Business plans (per user, per month, AI credits included) come with a 1-month free trial. Install the extension, open the Time tab on a work item you touched today, and see whether Friday timesheets stop being a chore.

Frequently asked questions

Does Azure DevOps have built-in time tracking?

Not in the timesheet sense. Azure DevOps provides effort fields on work items — Original Estimate, Remaining Work, and Completed Work (availability depends on your process template) — plus sprint capacity planning. These support estimation and burndown, but there are no time entries, timesheets, timers, approvals, or billable-hours features built in.

How do I track time in Azure DevOps?

Three ways: update the native effort fields manually (works for burndown only), log hours in a spreadsheet or external tracker and reconcile later (double entry), or install a time tracking extension from the marketplace that adds real time entries, timesheets, and reporting inside Azure DevOps.

Can I see hours per person per day in Azure DevOps?

Not with native fields. Completed Work is a single number per work item that gets overwritten on each update — it isn't broken down by person or date. To get per-person, per-day hours you need a tool that stores discrete time entries, such as a time tracking extension.

What is the difference between Remaining Work and Completed Work?

Remaining Work is the estimated hours left on a task and drives the sprint burndown chart. Completed Work is the running total of hours already spent. Both are single numeric fields — updating them replaces the previous value rather than adding a dated entry.

Can Azure DevOps track billable hours?

Not natively. There is no billable flag, rate, or client dimension on work items. Teams that bill by the hour typically add an extension that classifies entries as billable and supports approval before invoicing.

Is Hourdeck free?

Hourdeck is free for up to 3 users. Team and Business plans are priced per user per month with AI credits included, and every paid plan starts with a 1-month free trial. It's available through the Microsoft commercial marketplace and installs as an Azure DevOps extension.