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.
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 in a larger scale, it makes sense to use the budget feature. (For more info, please see Budgets Page Overview)