Page Comparison

Completed and Remaining Work fields tutorial video:

...

...

Question

We have data filled in a work item for the effort field but when we export the Budget to Excel the effort field is empty. Why is this happening?

Answer

The Budgets export does not look at the Effort field itself, but instead at whatever is selected in Work Item Automation settings for Pace Calculation:

If you select the Effort field for Pace Calculation, it will be reflected in the export.

Question

When an existing work item already has a value specified directly in Azure DevOps in the Completed Work field, and a subsequent work log entry is created using Timetracker, the Completed Work field value is updated to only reflect the Timetracker work log total, overwriting the previous Completed Work value.

Answer

The value entered manually into the Completed Work field will be overwritten with the data entered into Timetracker, since once Work Item Automation is enabled, and the Completed Work field selected, this field is used for filling the time tracked within Timetracker. So anything that is not entered into Timetracker will not be included.

Question

Is there a way to evaluate an engineer by comparing his evaluation of a task with the real time he spent on it? The challenge is to compare original estimations of efforts with the eventual tracked time.

Answer

There are several ways to achieve this - here are some starting points.

It's good practice to use the effort field for estimations in parent items (such as stories, PBI's or bugs). The effort can be a unit like story points, complexity points, or - even hours. So, the engineer first estimates the whole story, then breaks it down into tasks, and tracks time on the tasks. If you proceed like this, you can use the Timetracker pace field that indicates the ratio between initially-estimated effort and the eventual tracked time. As estimation skills are usually some kind of holy grail, this is very educational for the team to understand previous estimations after work has been finished. (Start here for additional information: Iterations Page Overview)

You will find the pace information in a lot of places in the Timetracker UI, e.g. in the "7pace Timetracker" tab (formerly the "Time" tab) from within the work item form, for every work item type, even high-level items such as epics.

In addition, the task itself will also be estimated during the process, this time (depending on your work item template in DevOps Server/Services) in the remaining hours field, in the unit hours, but in a different context. The number will usually get updated multiple times until this work is completed, as the engineer is supposed to report how much time from the current perspective is still remaining every day. For that reason, this field is not that suitable for comparing an initial estimation with the final tracked time, as it is intended to be used as the snapshot of now, how many hours remain in the sprint, e.g. to compute the burndown. 

However, if you need to compare the remaining hours with the tracked time, there are some tricks as well. First of all, DevOps Server/Services saves all ever-filled fields in estimations of remaining hours in the work item history. This data is available via the REST interface directly from DevOps Server/Services; you can get this for any given date. If you only need some samples, you can also open the work item itself with a browser and scroll down the history to see the initial estimation. You should keep in mind that there might be a huge number of entries for that field available, and it might be hard to automatically grab the correct value for meaningful analytics. (A good start for further information might be here)

Another option is to add an additional field in the work item template of your project in DevOps Server/Services that represents the binding initial estimation on the task perspective. This field should be not changed during the development process and can serve as a good helper to remember how the situation was estimated at the very beginning. 

If you want to track and control spending on a larger scale, it makes sense to use the budget feature. (For more info, please see Budgets Page Overview)