How to Set Up Sprint-Level Time Reports in TimeTrack

Sprint time reports in Azure DevOps give your team a factual record of hours spent against planned work each iteration. Install the free TimeTrack widget, scope it to your sprint, and you have the effort data you need for retrospectives and capacity planning.

Browse the QServices guides hub for more Azure DevOps walkthroughs.

What you need before you start

Before adding the TimeTrack widget, confirm the following are in place:

• Azure DevOps organization with at least one team project and a team dashboard already configured.
• TimeTrack extension installed from the Visual Studio Marketplace. It is free with no per-user fee and no subscription. Installing requires ADO organization admin rights.
• ADO project admin rights to add or edit widgets on the team dashboard. Once the extension is installed in your org, any dashboard editor can add the widget.
• An active sprint (iteration path) configured in ADO Board settings, so the widget can scope correctly to the current iteration.
• Developers actively logging hours on work items during the sprint. The widget aggregates only what is already recorded. If no time has been logged, the report will be empty. Agree on a daily logging habit before you expect useful data.

Step-by-step: Set up sprint time reports in TimeTrack

1. Confirm developers are logging hours on work items during the sprint. Open several active work items and check that time entries exist. The TimeTrack report aggregates only what has already been logged against ADO work items. It cannot infer or backfill missing entries. If you find consistent gaps, establish a daily logging routine before moving on. A standup reminder at the end of each working day is the simplest approach that holds.

2. Add the TimeTrack dashboard widget to your ADO team dashboard. Navigate to your team dashboard in Azure DevOps. Click Edit in the top-right corner, then Add widget. Search for TimeTrack in the gallery and add it. All time data is stored inside your ADO organization using the built-in extension data service. Nothing leaves your tenant. Once added, resize the widget to give the breakdown enough room to display clearly.

3. Scope the widget to the current sprint and your team. Click the widget settings icon. Set the Iteration field to your active sprint and select your team from the Team dropdown. This filters the aggregated hours to the work items your team owns in that iteration. If you manage multiple teams, add one widget instance per team rather than trying to combine them in a single view.

4. Choose the breakdown view that answers your current question. TimeTrack lets you view the same logged hours three ways. Use by developer for capacity planning: it shows who is carrying the most hours and where workload may be unbalanced. Use by work item type to see where sprint time actually went, such as how much went to bugs versus features. Use by date range for sprint-over-sprint comparison. Pick the view that matches the question you are bringing to the retro or planning session.

5. Read actual effort against planned work in the sprint retrospective. Share the dashboard link with your team in the retro. Compare logged hours in TimeTrack against your sprint goal and the velocity data in ADO Analytics. Gaps between planned and actual effort are the signal worth discussing. They usually indicate an estimation gap, scope that crept in mid-sprint, or work that happened off the board entirely. Naming the source of the gap leads to a more useful conversation than noting the total alone.

6. Use the date-range breakdown to compare effort across sprints over time. After two or three sprints of consistent logging, switch to the date-range view and widen the window to cover multiple iterations. Look for whether total hours are stable sprint to sprint, whether bug hours are growing relative to feature hours, and whether individual loads are evening out. At this point the data moves from a retro tool into a genuine capacity planning input.

Choosing the right breakdown for your question

TimeTrack's three breakdown views pull from the same logged hours but surface different signals. Choosing the right one before the meeting saves you from drawing the wrong conclusion out of the data.

Because TimeTrack data lives inside ADO alongside your task-completion records, you can cross-reference logged hours with ADO Analytics velocity and remaining-work data without exporting anything to a separate tool.

Where this gets tricky

The report is only as complete as the logging. If a developer misses two or three days of time entries in a sprint, those hours disappear from the aggregate entirely. The widget has no way to infer or backfill missing data. The most common failure pattern is a team that logs diligently in the first half of the sprint and stops as deadline pressure builds, which is exactly when the data would be most useful.

Work that happens off-board is the other persistent gap. Meetings, support requests, and ad-hoc tasks that are never created as ADO work items do not show up in the report at all. If a meaningful fraction of the team's week goes to work that never touches the board, the sprint report will systematically undercount actual effort.

TimeTrack reports hours against work items. It is a sprint effort visibility tool, not a billing timesheet or payroll record. It does not track leave, public holidays, or non-project time. If you need a compliant record for client billing or payroll, TimeTrack is not designed for that purpose and you need a dedicated time and billing system.

How QServices can help

TimeTrack is a free QServices extension for Azure DevOps teams. Install it from the Visual Studio Marketplace with no subscription and no per-user fee. It gives ADO teams sprint-level effort visibility with no server setup required, as long as developers are logging time on work items.

If your team needs more than sprint time reports, such as automated backlog creation from meeting transcripts, sprint capacity tracking driven by an AI agent, or real-time Power BI velocity dashboards replacing manual note capture, that is the kind of project we take on as a Microsoft Solutions Partner. Our Smart PM engagement for an IT services company covered exactly this territory: automated meeting transcript capture feeding Azure DevOps backlog creation with Fibonacci story point assignment and live sprint velocity dashboards built on Azure AI Foundry.

To extend your ADO setup beyond basic time tracking, explore our AI agent development services or talk to our engineering team.

Do I need admin rights in Azure DevOps to use TimeTrack?

Organization admin rights are required only for the initial extension install from the Visual Studio Marketplace. Once TimeTrack is installed in your ADO organization, any team member with dashboard edit rights can add the widget. Viewing the dashboard and reading sprint time data requires only standard project member access, with no elevated permissions needed for day-to-day reporting use.