KKelly's Weblog

Delivering Work Items

2005-05-17T23:13:00Z

Okay, I know it’s been awhile since I jumped in the fray here, but here you go ….:-)

An update on what I’ve been doing… I’ve spent this year executing project management activities for the work item tracking features in Team Foundation Server. We’re turning this carrier into the wind now, readying for a lunch later this year. That’s allowed me to reflect on what we’ve done and begin to make plans for our next release. I’m out visiting people evaluating the Beta and talking to others beginning their adoption planning. To be honest, we’ve left a lot of features on the table in this first version. Some of you will find things that are unnacceptable and others have brilliant ideas for what we should do next. I’d like to use this weblog as a forum, an intellectual commons even (yikes), to discuss what must be in the next release. I’ll seed things with reports of what I’m hearing. I hope some of you will help me sharpen my observations or tell me I need a hearing aid.

This week I’m in Atlanta. Yesterday I attended one of the first local Visual Studio 2005 events to be hosted by our field sales team. There were almost one hundred people at our conference center in Alpharetta.

Some smart guys from a major power company based here got me thinking about how work items are delivered to developers. In Team Foundation we rely on a query to communicate the list of work in someone’s queue. You have to run a query to see your work items. Their point to me was what if you could just sync to your sources and have all the Work Items embedded in the code show up in a list in the Task window. In their scenario the source code contains links to work items. The code attributions come from collaborators (lead, reviewer, or tester). Collaborators describe details in a work item (bug, task, or suggestion) and then leave the link to it in the source file. We have the pieces for this scenario already in Visual Studio: support for attributed code, a task window, and now with Team Foundation we have the linking infrastructure. I’m intrigued and will think about how we might do this sooner then later. Keep you posted. Let me know what you think.

-k2

Not all work items are created equally

2004-06-03T05:24:00Z

I’ve been managing the flow of work items on various Visual Studio teams at Microsoft over the last several years. One perennial challenge is separating and analyzing trends of real, code churning work items (bugs, defects, design changes, etc.) from little adhoc work items (suggestions, spec clarifications, Todo’s, etc.). They’re all important in some context, and it’s great to be able to count them and exclaim “we’ve got 6,532 work items in the database!”

As a project manager I really want to minimize the time people spend processing these work items.

Now 6,532 is a big number, much bigger than most projects will every have, but it’s not outside the range for a project like Microsoft Office, SQL Server and Visual Studio. And in fact, the total work items processed over the course of a two year project is in the tens of thousands. Work flow over half the project cycle is fueled by these work items.

If I could monetize the cost, I believe I’d find a model where I spent pennies (meaning, no process) on little items and dollars (high process) on big items. The way our systems are set up, we spend the same processing all items. As we near the end of a project each is touched many times; they can be opened, triaged, investigated, costed, approved, fixed, code reviewed, resolved, and verified, each by a different person. Almost everyone is scurrying to get work items off their plate. Note: I’m just talking about handling costs here, not the cost of actually accomplishing the work item!

Frighteningly, at Microsoft we call all these work items “Bugs”, although a large percentage isn’t.

Our process makes it really cheap for anyone to open a Bug. That is, make a comment, suggest a change, raise a concern, or open a real product defect. We want this. But it does create a kind of “curse of the commons” problem. Hundreds of people, opening tens of Bugs, adds up quickly. The trending reports rarely differentiate types. So although I’m trying to measure our state and predict our trends toward stability, I find I’m swimming in an ocean of little work items that obscure our view. At times I’ve resorted to sampling to better measure the nature of our “bug debt”. We’ve added fields to help categorize but they’re just add even more clutter to the Franken-form. They get ignored often enough that I don’t trust them after awhile. When we make it a required field it’s perceived as yet another tax and we find we're working against ourselves, making it harder for the average Joe to open a bug.

This is one perspective that led us toward a multi-type work item system. In Team System you’ll associate work item type definitions to a project, they’ll have their own form, rules and work flow. In my nirvana, I’ll have a type for scheduled work items, a type for defects, and a type for issues – this is the type for someone who needs to get something off their chest. And when a defect report turns out to really be a feature request, I’ll be able to change the type from defect to scheduled work item. Making the subtle change of forcing type selection when opening a work item still keeps the users cost small, and has the secondary effect of narrowing the users form so they only have to deal with the specifics of the type. As the project manager I can focus my formal process on the defects and less formal processes on the scheduled items and issues.

I’d love to hear peoples reactions…

Why Work Item Tracking?

2004-05-29T00:01:00Z

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.