During software engineering consulting engagements I spend quite a bit of time learning how each team works together to do what they do.  Much like the beginnings of a software project, I go through an investigation phase where I literally ask questions such as, “When Sue does X and copies the files to Y who picks them up and does Z?”  The goals of the investigation are: figure out how to measure the work that is happening, identify work that is on the “we really shouldn’t be doing that” list, and find gaps in the team’s workflow.  Although the last two are very important and are high on the ‘bang-for-your-buck’ scale, the ability to measure work will result in the most mileage for your team since that's how you identify bottlenecks in your team.  When you find a bottleneck, the question to answer is “how do you unblock the blocked or make the slow faster?”  Since you’re working with people, there are often unpredictable personnel reasons why bottlenecks exists, if we eliminate the personnel reasons for bottlenecks, it comes down to (either slow or non-existent) decision making.  These decisions, which are sometimes made by the software team, the operations folks, or the end user/customer, are based on previous decisions.  This context can be considered the Requirements of the project since they have to be considered or enforced for the project to succeed.  So the question is, “how and where do we store these decisions?”  Although they can be stored in a simple spreadsheet, document, or database, significant value can be achieved if they are stored in a database where they can cross reference each other and other project artifacts (such as Source Code, Builds, Tests, etc…)   With Microsoft Team Foundation Server Work Item Tracking you can do exactly that.

It’s important to break down the kind of information that is stored in TFS Work Items.  I think of it as a stack of information classes, where at the bottom are ‘things that need to be done by people’ (aka Tasks and Bugs) and as you go up the stack it becomes ‘decisions that need to be considered or enforced by people who are doing the things’ (everything else).  Since this article is not about bugs or defects, we’ll consider Bugs as equivalent to Tasks since they represent work that needs to or may get done.  At the top of the stack are Business Requirements such as Vision, Mission, Scope, Business Goals, etc…  As you go up the stack from Tasks to Business Goals, the scope increases and vice versa.  For example, quality of service requirements are often relevant to components of a system (higher) or a set of features whereas functional requirements are usually specific to a feature that a user will experience while going through a scenario (lower). 

At the end of the day, these work item types are defined by the kinds of work done and type of decisions that people make on a daily basis.  Once you identify who does what on your team and track the dynamics of the relationships between work and decisions you will be able to identify bottlenecks and make appropriate changes to either your team or the process (the way the team works together) to improve quality and efficiency.  Most importantly, you’ll finally have a view into the dynamics of the team which in the worst case can become the loathed black box.