Work Items, Work Items, Work Items

February 2007 - Well this month has been interesting. I spent the first half on the beech in Hawaii with a cocktail, great wife, and a good book (actually four of them). And the second half here at work making up for the two weeks I had off. Makes you wonder if vacation is really worth it?

In January we looked into work item tracking as that is much of upper management's focus. They like the states and transitions and have hours of fun drinking coffee, taking golf, and designing elaborate workflows that no one understands. We're using the CMMI process templates and then making our (i.e. upper management) modifications from there.

In the Change Request work item we're changing the default states to Submit, Estimate/Evaluate, Implement, Verify, Close. Why? Not sure, but this is what the big wigs wanted. At our company we call Bugs, Defect Reports. From what we can tell changing the name of Bug is impossible if a Team Project is already created. So we negotiated and decided to call a Defect Report a Bug when in TFS. We changed a few fields and changed the states to Submit, Evaluate, Implement, Verify, Close. Again, we're at upper management's mercy.

Both Issue and Risk we left pretty much the same. We added a few fields, but for the most part they're out of box. We're not 100% sure on how to use Requirement. Another group is looking at purchasing what they call a Requirements Management tool so we'll probably wait until that effort fails before we start looking at the use of our Requirement work item. That being said, my boss just stopped by my cube and during a lively chat we might have found a use. More on that to come in future months. The Review work item we plan on making optional if they want to use it for code/document reviews.

Task is the most complicated. Tasks are where all our release related work items are stored. If our release manager wonders what are all the changes going into release 7.7, they simply look at all the Tasks with the Release Number (i.e. changed the name of Iterations to match our terminology) set to 7.7. If our other application tiers (e.g. Application Tier) who are dependent on us needs to know all the changes, they typically look at the Tasks. Change Requests are typically to high level for developers. Using Tasks we also get a good idea when it's time to baseline. I won't get into all our states and transitions (far to many to explain here), but basically we have a state called Code Complete. Before we baseline a release (e.g. 7.7) we look to see how many Tasks are in Code Complete. Ideally all of 7.7 Tasks should be, but as it happens a few are always still in Active or Code Review. We typically move forward with the baseline, but know there is work to be done on the release before a comprehensive round of testing can start.

Development is also supposed to create Links so we have a good understand of what Tasks created Bugs, and what Change Requests or Requirements, Tasks are assigned to. In a perfect world (which we're far from) a Change Request or maybe Requirement (in the future) is submitted. One or many Tasks are assigned to Change Requests or Requirements. Then during the Task's Testing state, Bugs are created and Linked to the Task. Taking this further, Reviews, Issues, and Risks can also be Linked to the Task. This all being said, without rules to enforce a Linking hierarchy, it's really hard to make sure people follow these guidelines.

We also created two new work items. The first is called Build where we log all build results. We're a Java shop and not using Team Build (currently using Anthill which we also wrote a TFS adapter for http://bugs.urbancode.com/browse/ANTHILLOS-261) but still want to keep all our build results (e.g. build failed/succeeded) in TFS. One stop shop for all information. We simply create a Build work item, update it with the needed build information, and close it when the build is done. Seems to work alright. Then we also created Environment CR, which is used to track environment changes. These are handled differently then other Change Requests so that is why we created a different work item for it.

Anyway, probably enough information for the month. We'll touch base in March when all of what I said above changes. Happy winter!