Chris Menegay on VSTS Work Item Tracking & Project Integration
Chris Menegay posted some thoughts on some of the project management features of Team System. It looks like he's very excited by the Work Item Tracking functionality:
It seems that the more I play with VSTS, and learn cool new things, the less likely I am to blog about it. I find myself talking to people about Team System almost every day, but constantly don't think to record some of the more interesting bits here. So--- If you haven't looked at the full feature-set yet, you need to check out work item tracking (WIT). WIT is my favorite piece of VSTS, it allows you to manage and track your work, your bugs, risks, etc.
It's great to hear this kind of feedback on the Work Item Tracking components. I'm not sure how many CTP users have spent much time with these pieces of Team System, but I'd love to hear comments/feedback from anyone else.
However, Chris isn't so chuffed with the MS Project synchronization:
However, I'm extremely disappointed with the MS Project synchronization, I'm curious to see how that evolves prior to release. The problem is this: I think a developer should access their work items within VS, and know exactly what they should be working on. As they complete a portion of a task, they should be able to (from VS) mark it partially complete. The PM would then sync that data and update the project plan with % complete.
This is great feedback – and Chris, you're absolutely right. Our Project synchronization story isn't great in the CTP – and I'll tell you right now that these problems won't be fully addressed in the Beta 2 release. You'll probably see some changes since the CTP. The work item definitions have been cleaned up a bit, and a developer can at least mark Tasks as partially complete using the “Completed Work” and “Remaining Work” fields and have them round trip into Project. This is still quirky though – the ratio of completed work to remaining work is used to calculate a % complete value for the task, regardless of the Duration value in the task in MS Project.
Neither of these scenarios are supported today (Dec. CTP). If a developer has 10 work items, there is no "start date" on them to indicate an order. Within a project plan, the PM usually sets that up, but there is no field to hold that in the work item itself. One of the guys that I work with is going to be exploring soon how hard it would be to add the additional field to the work items, and then modify the field mapping to Project. That way, if MS doesn't fix this, we'll have a solution. The same would need to be done for % complete data - though I think that may be there in beta 2.
I'm happy to see that Chris is looking into the extensibility story. We fully expect to see organizations do some degree of Work Item Type definition customization in order to fit in with their methodologies & development processes. I'd love to find out how well other people are progressing with extending the out of the box CTP Work Item Types.
Another annoyance is that people "assigned to" a work item, don't map to the "resource" within a Project task. This requires you to manally synchronize these important data items. I'm not sure what the product team is thinking on this, and I've already passed along my feedback. Of course, if MS doesn't correct these issues, and I can get them working on my own, that just means there is some opportunity.
In v1.0 of the Work Item tracking components, we don't support multi-valued fields. In other words, “assigned to” can only be set to a single person. MS Project's “resource” is a multi-value field; multiple people can be assigned to work on a single task. This isn't something that we can round trip in a straightforward way at the moment.
Our MS Project synchronization story does need some work. I was just chatting to the Dev Lead of the team working on these features. He's a recent addition to the team and I'm happy to say he's very passionate about addressing the issues Chris raised (and many more). Obviously we're not in a position to make any promises about exactly what this will look like, but I think it's fair to say that we'll see some significant changes after Beta 2.
