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 in a larger scale, it makes sense to use the budget feature. (For more info, please see Budgets Page Overview)
Comments
2 comments
I don't think this answers the question - and it's a pretty fundamental requirement of a time-tracking utility. For each of the tasks in my project, how much time was spent compared to how much time we thought it would take?
I'm wondering if it's one of those things that's so obvious we're missing it!
Update on this matter -
Best practise for the demand of only compare an original estimate of hours with the eventually tracked time: (1) Make sure you have a field in DevOps Boards where you fix the original estimate. If that field is not present, you can add this as a custom field in DevOps/TFS. (2) Have 7pace Timetracker automatically update the completed work field of the work item. (3) You have now all required information at every place in your environment at hand. You can either use that in a custom query in DevOps, see it in Times Explorer, export for further analysis in Excel or other tools, or use 7pace API's, or you even can create a roll up as described here: https://docs.microsoft.com/en-us/azure/devops/reference/xml/support-rollup-of-work-and-other-fields?view=azure-devops
We will release our new built-in reporting feature in summer 2019; there will be a predefined report in one of the dashboards presenting this information with roll ups. This will anyways also require the pre-requisites described above in (1) and (2).
Please sign in to leave a comment.