none
Mapping Work Estimate Field in TFS to Baseline Work in MS Project

    Question

  • I wanted to get anyone's input on mapping the Work Estimate Field in TFS Tasks/Bugs to Baseline Work in MS Project; or any ways you as a project manager are using the original Estimate field set in TFS to track your project's progress in MS Project.
    Tuesday, May 08, 2007 3:51 PM

Answers

  • The idea is to help you improve the quality of your estimation: you keep the original estimate you made of the work required for a task or requirement, and then compare it with the actual work required. So if you're using all three fields Original Estimate, Remaining Work, and Completed Work, you start off with Original Estimate == Remaining Work. In the Retrospective at the end of the iteration, you can look through your closed work items and see the differences between the Original Estimates and the actual Completed Work. Write a simple query to find the ones with the biggest differences. Enquire why the difference was so big, and how you can avoid that pitfall next time. Sometimes it's just a question of resetting expectations in particular areas; sometimes it's about identifying, and doing preliminary investigation on, the most uncertain aspects of the work.

     

    That strategy works on projects where each team member keeps up to date the Remaining and Completed figures on the tasks they're doing. It isn't really the overhead it sounds: it's actually quite useful at the end of each day to spend a minute thinking "how much time have I spent on this? how much longer is it going to take?" In our daily standup meeting, we to project on the wall the spreadsheet of all the current tasks, with their remaining and completed work figures. As each person says what they've done, what they're about to do, and whether there are any blocking issues, we filter the spreadsheet by the tasks they currently own.

     

    Some teams prefer a coarser approach: they don't use Remaining and Completed, but just count the tasks outstanding. The idea is that the tasks - which are of course broken down to be no more than 2 or 3 days - average out roughly the same size, and are fine-grained enough by themselves to be a measure of progress. In that case, the Original Estimate is still very useful: in the project's early retrospectives, you find out the factor that relates it to numbers of tasks.

     

    If you're interested in checking exactly what mappings are set up between Project and TFS fields, take a look at "Customizing Microsoft Project Field Mappings". If you want to change the mappings for all new projects you create, look at the Project Field Map section "Classification" in "Customizing Process Templates".

    Sunday, June 15, 2008 10:41 AM

All replies

  • Hi Jennifer,

     

    Sorry for the delayed response.  Are you still looking for help with this issue?

     

    Matt

    Thursday, August 02, 2007 6:22 PM
  • I am interested in the same solution that Jennifer asks for.

     

    Besides that how is the appropriate way to use the baseline work field in TFS<->Project? I can not see any changes in my plan when I update that field.

     

    Thanks,

    Martin Kulov

     

    www.kulov.net

     

    Wednesday, May 07, 2008 3:31 PM
  • The idea is to help you improve the quality of your estimation: you keep the original estimate you made of the work required for a task or requirement, and then compare it with the actual work required. So if you're using all three fields Original Estimate, Remaining Work, and Completed Work, you start off with Original Estimate == Remaining Work. In the Retrospective at the end of the iteration, you can look through your closed work items and see the differences between the Original Estimates and the actual Completed Work. Write a simple query to find the ones with the biggest differences. Enquire why the difference was so big, and how you can avoid that pitfall next time. Sometimes it's just a question of resetting expectations in particular areas; sometimes it's about identifying, and doing preliminary investigation on, the most uncertain aspects of the work.

     

    That strategy works on projects where each team member keeps up to date the Remaining and Completed figures on the tasks they're doing. It isn't really the overhead it sounds: it's actually quite useful at the end of each day to spend a minute thinking "how much time have I spent on this? how much longer is it going to take?" In our daily standup meeting, we to project on the wall the spreadsheet of all the current tasks, with their remaining and completed work figures. As each person says what they've done, what they're about to do, and whether there are any blocking issues, we filter the spreadsheet by the tasks they currently own.

     

    Some teams prefer a coarser approach: they don't use Remaining and Completed, but just count the tasks outstanding. The idea is that the tasks - which are of course broken down to be no more than 2 or 3 days - average out roughly the same size, and are fine-grained enough by themselves to be a measure of progress. In that case, the Original Estimate is still very useful: in the project's early retrospectives, you find out the factor that relates it to numbers of tasks.

     

    If you're interested in checking exactly what mappings are set up between Project and TFS fields, take a look at "Customizing Microsoft Project Field Mappings". If you want to change the mappings for all new projects you create, look at the Project Field Map section "Classification" in "Customizing Process Templates".

    Sunday, June 15, 2008 10:41 AM