Why Work Item Tracking?

Brian White asked me this week at Tech*Ed how we settled on the terms work item tracking to “brand” our features of the new Visual Studio Team System. A good question to kick off  for my first weblog post…

The history of it, like most of these stories, is actually pretty unglamorous.  As we started spinning up our team, we quickly recognized we were swimming in a terminology soup.  In every presentation or conversation it seemed we had to baseline the discussion with something that came out “umm, yeah, the new bug-task-issue tracking system…”.  Inside MS we just call every record that lands in the project databases a Bug.  So when you hear stories about how so-and-so team shipped with 1,200 bugs…the correct interpretation is that they had 1,200 tasks (another term!) that just didn’t get done in time.  Going to market calling the feature by any single term (like bug tracking) just seemed limiting. Oh and then there’s the Bug vs. Defect debate…please stop.

We knew we had to settle on something…ideally somewhat unique, and something folks would just get.  The essence of our system helps teams manage discrete units of work, assigned to individuals and, when taken as a whole, it represents all activities (another famous term! and taken) managed in a software development project.  They’re all the work items of a project…work item tracking.  Teams define the types of work items they want to track…and i’ll leave details of this for later posts.