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…
Comments
Anonymous
June 02, 2004
This is basically what we have done at work for the last ... maybe 4 years.
The only thing to be careful of is whether the reclassification of a work item would offend the originator of it. I don't know if your system notifies the creator when such things happen, but I sometimes would prefer to just change the type without any emails going out.
This isn't really an issue for internal people, unless they're very political or take things personally ... but it is an issue when the originator is external, like a client or customer.Anonymous
June 07, 2004
I love how this sounds. I hope it is easy to implement and train people how to use.Anonymous
June 07, 2004
The comment has been removedAnonymous
June 29, 2004
You know I like work item types, Kevin :)
I just hope you guys figured out a ... relatively painless way to change types, considering field X may be required in type A and not even valid for type B (or vice versa).
The reverse one is actually more interesting - what does the user do if he wants to make this issue into a defect, but doesn't know what value for a required field is appropriate?
Of course, there's a school of thought that says NO fields should be truly required; hopefully the set of required fields is truly as small as possible, such that any user of that work item type knows how to treat all of the required fields.Anonymous
July 21, 2004
Sorry, I'm not really technically-minded enough to comment on your post. But I just wanted to say hi from a fellow Kevin Kelly and weblogger, based in Ireland.Anonymous
July 21, 2004
Oops, got my domain wrong in the previous comment. Drop by and leave me a message!Anonymous
March 27, 2008
PingBack from http://employmentwagesblog.info/kkellys-weblog-not-all-work-items-are-created-equally/Anonymous
June 09, 2009
PingBack from http://quickdietsite.info/story.php?id=14623Anonymous
June 15, 2009
PingBack from http://einternetmarketingtools.info/story.php?id=23665