At Associated Electric, we leverage Microsoft’s Team Foundation Server (TFS) for work tracking and a source code repository. Over the years I have customized and built out work items to help me manage and stay on top of the work my team is doing. I have also experimented with some of the forecasting and scheduling functions of TFS, i.e. burn downs, kanban boards, task boards, etc. The challenge with many of these functions is that the data required to make them work can be intense. A medium sized project may consist of a single TFS work item, with a dozen or so user stories and those user stories may have half a dozen tasks all requiring a half dozen or so fields just to communicate the work, who’s doing it, and when. Getting a burn down and accurate forecasting in TFS requires at least another half dozen fields and if you don’t take the time to think about each of those fields having them won’t provide you with any value. For a project like this you may easily spend a day to two just keying work items in to TFS, not a very exciting endeavor for an analyst or developer. I just settled by using story points on the user stories and not bothering with the task level, but I was always hungry for more out of TFS.
Recently I had to spend an extended amount of time away from managing my team and when I returned, I discovered that things were not running as well as I would have hoped. It is nothing against my team, they are just trying to execute on work the best they knew how. It became obvious to me that I needed more insight into all the work going on in my team and they needed more clarity on priories. Across my team there is a large range of work, everything from writing annual reviews, tier two user support, and implementing ASP.NET web applications. The one thing that all work has in common is that it can all be abstracted into tasks. Tasks that can be scheduled and prioritized in TFS.
I also discovered that in TFS 2015, there are service hooks including a generic web hook that can be called on work item creation and updates. From there my creativity exploded. All of my team’s project milestones and support requests are modeled as User Stories, and using the TFS REST APIs, I created a web hook that automatically created a child task for the implementation of the project milestone, or resolution of the support request. I even plugged into the time tracking data we maintain to populate time estimates into these tasks based on the TFS area. Doing that instantly enabled me to start leveraging the TFS Task board with accurate time estimates with absolutely no additional data entry. I also implemented a web hook for work item updates to automatically close the parent user story when all child tasks are closed. I created a second update action to propagate changes from the parent user story down to all active children, i.e. if you carry a user story forward into the next iteration, the iteration will automatically update for the remaining child tasks. By automating this data entry, my team is now using the Task Board which give me a single place to review all the work going on and give me the opportunity to easily guide and correct work priorities for team members. All of this is happening without any additional data entry on my part. I’ve included the models that you can use to deserialize the JSON calls from the TFS Service hooks to help anyone else get started.