How to Log Time on Azure DevOps Work Items: Native Fields vs. a Timesheet Extension

Azure DevOps does not ship with a time tracker. What it ships with is a handful of effort fields on work items — cumulative hour counters you overwrite by hand. That's enough for sprint capacity math, but the moment you need to know who spent how many hours on what, on which day, the native route runs out of road.

This guide covers both ways to log time on Azure DevOps work items:

1. The native route — the built-in Completed Work and Remaining Work fields, step by step, including their real limits.
2. The extension route — adding a timesheet layer inside Azure DevOps with Hourdeck, so time becomes dated, per-person entries with a timer, a weekly grid, and approvals.

What "logging time" means natively in Azure DevOps

Out of the box, Azure DevOps tracks effort with process-template fields on work items:

• Agile and CMMI processes: Task work items carry Original Estimate, Remaining Work, and Completed Work (all in hours), grouped under Effort on the work item form.
• Scrum process: Tasks only carry Remaining Work. There is no Completed Work field unless you add it yourself through an inherited process.
• Basic process: Issues carry a single Effort field — no hours breakdown at all.

The key thing to understand: these are running totals, not time entries. Completed Work is one number per work item. Logging "3 hours today" means reading the current value, adding 3 in your head, and typing the new total. Azure DevOps stores no dated record of that increment — only a field revision in the work item history.

Route 1: Log time with the native fields

Step 1 — Confirm the fields exist on your process

Open any Task and look for the Effort group (Original Estimate / Remaining / Completed). If you're on Scrum or Basic and the fields are missing, an organization admin can add Microsoft.VSTS.Scheduling.CompletedWork to the work item form via Organization settings → Process → (your inherited process) → Task → New field → Use an existing field. You can't edit the locked system processes directly — clone to an inherited process first.

Step 2 — Update Completed Work on the task

1. Open the task from the sprint backlog or Taskboard.
2. Read the current Completed Work value.
3. Add today's hours to it and type the new total (e.g., 5 already logged + 3 today = 8).
4. Subtract the same hours from Remaining Work — Azure DevOps does not do this for you.
5. Save.

For quick passes across many tasks, the sprint Taskboard lets you edit Remaining Work inline on each card, and the backlog's column options can expose Completed Work for bulk editing in the grid.

Step 3 — Automate it if you must (REST API)

If you're scripting, the fields are plain work item fields — a PATCH to the work item updates them:

``json [ { "op": "add", "path": "/fields/Microsoft.VSTS.Scheduling.CompletedWork", "value": 8 }, { "op": "add", "path": "/fields/Microsoft.VSTS.Scheduling.RemainingWork", "value": 4 } ] ``

Note that the API has the same semantics as the UI: you're overwriting a total, so any automation must read-then-write, and two concurrent writers will silently clobber each other.

Step 4 — Report on it

There's no native "hours by person by week" report. Your options:

• Build a work item query with Completed Work as a column and export to Excel/CSV, then pivot manually.
• Wire up Analytics views / OData into Power BI and build the rollups yourself.

Where the native route breaks down

The native fields were designed for sprint burndown math, not timekeeping. In practice you hit these walls fast:

• No dated entries. One cumulative number per work item — you can never answer "how many hours did Priya log last Tuesday?"
• No per-person attribution. If two people work the same task, their hours merge into one field. Last write wins.
• Manual arithmetic, twice. Every log is a mental add on Completed Work and a mental subtract on Remaining Work. People skip it, and the data rots.
• No timer, no timesheet view. Logging is per-work-item form edits; there's no weekly view of your own time to sanity-check before Friday.
• No approvals or billability. Nothing distinguishes billable from internal hours, and no one signs off on anything.
• Reporting is DIY. Every rollup means Excel exports or a Power BI/OData project.

If all you need is a rough burndown, stop here — the native fields are fine. If time drives client billing, capacity decisions, or payroll-adjacent reporting, you need real time entries.

Route 2: Log time with an extension (Hourdeck)

Hourdeck adds a full timesheet layer inside Azure DevOps — an extension hub plus a Time tab on every work item — so nobody leaves the tool they already work in. Time becomes what it should have been natively: dated, per-person entries attached to work items.

Step 1 — Install the extension

Install Hourdeck from the Visual Studio Marketplace into your Azure DevOps organization (a Project Collection Administrator does this once). A new hub appears in your project navigation, and each work item gets a Time tab. It's free for up to 3 users, so a pilot costs nothing.

Step 2 — Start a timer from the work item

Open the work item you're about to work on and hit the one-click timer on its Time tab. Stop it when you switch tasks. Each start/stop becomes a discrete time entry — with a date, a duration, and your name on it — instead of an anonymous bump to a shared counter.

Step 3 — Fill the gaps in the weekly grid

The weekly timesheet grid shows your whole week across work items in one screen. Forgot to run the timer Tuesday afternoon? Type the hours directly into the cell. This is the view the native route never gives you: your own week, at a glance, editable in seconds.

Step 4 — Let AI draft the week you forgot

The part that actually fixes timesheet compliance: Hourdeck's AI draft reads your own activity trail in Azure DevOps — your commits, work item comments, and work-item activity — and proposes a filled-in week mapped to the work items you actually touched. You review, adjust, and confirm. Reconstructing Thursday from memory becomes a two-minute review instead of a twenty-minute archaeology dig. Hourdeck also runs evidence-aware billability checks, flagging entries that don't line up with the activity behind them — useful before hours turn into an invoice.

Step 5 — Submit, approve, report

Submitted weeks route to a lead or manager for approval, giving billing a clean sign-off gate. On the reporting side, Hourdeck's pivot reporting needs no setup, no query language, and no separate reporting project — slice hours by person, work item, iteration, or date range directly in the hub, in the same place the team plans sprints.

Already tracking time in another tool? Hourdeck offers a one-click history import from other time trackers, so switching doesn't orphan your historical data.

Native fields vs. timesheet extension

Which route should you pick?

Use the native fields when hours only feed the sprint burndown, one person owns each task, and nobody outside the team ever asks for a time report.

Use an extension the moment any of these are true: you bill clients by the hour, more than one person touches the same work items, someone asks "where did last month go?", or timesheet-chasing has become a recurring standup topic. The native fields can't answer those questions, and no amount of process discipline changes their data model.

If that's your situation, try Hourdeck free — it's free for up to 3 users with no time limit, and paid plans come with a 1-month free trial, so you can run a full sprint's worth of real timesheets inside Azure DevOps before deciding anything.