Not all work items are created equally

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…