Howard wants feedback on his Scrum Work Item Type definitions for Team Foundation

  • Article

I mentioned yesterday that Howard van Rooijen is working on Team Foundation process templates for Scrum Methodologies.

Today he has posted details of the Work Item Types - if you've used Scrum, I highly recommend that you take a look and give him some feedback about what he's chosen to put in the work item types.

Personally, I'm not an expert in Scrum, but his work item types look simple and lightweight. He uses a couple of work item types to gather general information: one about the current Sprint, one about product requirements ("Product Backlog" work item). The main "work item type" to represent Tasks, Bugs, Impedments etc is the "Sprint Backlog Item".

The choice of creating a general work item type Sprint to collect information about things like the number of hours a day the team can work etc is interesting, because it highlights one way you can store metadata about your current project. Thinking about it, perhaps we should be exploring ways to define meta data for project iteration and area hierarchy, and on the project itself, that can be linked to from work items. This isn't going to happen in v1 - but I'd love to get some feedback on this for future work.

An alternative to creating a work item, is to create documents and put them on the project's Sharepoint portal, and then link to these from the sprint work item - but then you lose the ability to create simple reports about all the active Sprints etc.

Another couple of thoughts on Howard's work items - my comments might be due to a lack of experience with Scrum though, but I though they'd be useful to post here just so you can see some of my thoughts about Work Item Type design in general.

  • The Sprint and Product Backlog work items don't appear to be able to be assigned to an owner. Personally, I feel most comfortable having every entity in a project assigned to someone in order to ensure that someone is ultimately responsible for keeping things updated, or a contact point etc.
  • The Sprint Backlog Item will be overloaded for Tasks, Bugs etc - in general we're trying to encourage folks to consider using different work item types for these sorts of things, because often they actuall end up needing different fields, and different workflow. It's a hard call though - sometimes the difference between each work item type is so minimal (one field, for example) that this doesn't make sense
  • The Sprint Backlog Item doesn't appear to have a state when an item can be "signed off". In the MSF Agile bug, it can transition from Active->Resolved when it is complete - at which point it gets reassigned to whoever opened the bug to ensure the work has really been completed. When a Tester comfirms this, it then transitions to "Closed" - we call this "regressing the bug" at MSFT. Howard's Sprint Backlog work item currently gets resolved directly to a "Done" state - but there is no sense of this sign-off phase.

Just a few thoughts - but I'm really excited to see this work happening.