Welcome to EMC Consulting Blogs Sign in | Join | Help

Howard van Rooijen's EMC Consulting Blog (2004 - 2010)

This blog has now moved to http://howard.vanrooijen.co.uk/blog - please update your subscriptions if you wish to receive new content.

Agile Software Development with Scrum for Team System: Work Item Types

In Team System the Work Item Type (WIT) is the currency of application – you use them to define your tasks, requirements, bugs etc… This data is stored in the Team Foundation Server data warehouse and can be queried either by using the Work Item Query Language (WIQL) or by coding against the data warehouse fields in SQL Server 2005 Reporting Services. The WIT data can also be exported to Microsoft Project and Microsoft Excel – where it will be presented in tabular form, which will allow for rapid editing / updating of the data. Any changes made can then be synchronised back to Team Foundation Server.

WITs are defined by an Xml document that consists of three parts:

  1. Field Definitions – this is where new types are defined and configured (such as default value, whether the field is required and what its help text is)
  2. Workflow – this allows you to define the different states of the fields and the legal state transitions they go through
  3. Form Layout – very simple tabular layout for defining where the fields should be placed on the form.

Scrum is a very light-weight framework (Ken Schwaber states that it's not a methodology - because it doesn't tell you what to do - it is most analogous to the rules of a game) and thus in the current build of our Scrum plug-in for Visual Studio Team System - “Agile Software Development with Scrum for Team System” - we only have three different Work Item Types:

  1. A Sprint
  2. A Product Backlog Item
  3. A Sprint Backlog Item (represents Tasks, Bugs and Impediments)

I'll describe them in more depth in the following sections:

 

Sprint:

The Sprint WIT represents the iteration in which the development team is going to deliver working software. It is very light-weight WIT but should let you capture all the information you need. The complete list of fields for this WIT are listed below:

Sprint Work Item Type

Fields:

Title - Name of Sprint
Sprint Number - The number of the Sprint
Capacity - The number of available hours the team can work during the Sprint
Sprint Start Date - The date the Sprint starts
Sprint End Date - The date the Sprint ends
Current Status - This is the status of the sprints as selected by the user. The choices are:
  • Done – Sprint completed
  • Not Done- Sprint to be completed
  • Cancelled –Sprint was cancelled part way through

Description - Field that can be used to record any relevant sprint information such as general goal, team holidays etc
History - This field shows any changes made to the Sprint item and by whom
File Attachments - allows you to attach any related documents to the Sprint 

 

Product Backlog Item:

The Product Backlog WIT represents a requirement made by "The Business". It is defined using business terminology (not technical), assigned a value of importance to the business, and the effort required to complete the requirement is given in days. The complete list of fields for this WIT are listed below:

Product Backlog Item Work Item Type

Fields:

Title - This is the name and/or number of the product backlog item
Estimated Effort - This is the estimated time that it will take for this item to be completed - usually measures in days
Relative Value - This is the defined business value of this product backlog item.
Sprint Number - The Sprint Number that the Product Backlog Item will be developed in. This does not have to assigned as soon as the item is created - it can be assigned as the project progresses
Work Remaining - This field is automatically populated once Sprint Backlog Items have been associated to their parent Product Backlog Item. It shows the work remaining (in hours) - aggregated from all child Sprint Backlog Items.
Current Status - This is the status of the product backlog item as selected by the user. The choices are:

  • Not Done - no work has been started on this product backlog item
  • In Progress  - work is currently underway on this product backlog item
  • Deferred - work was started on this product backlog item but has been halted. The item is deferred and will be worked on again in the future
  • Done – product backlog item is complete and production quality

Description - This is the full description of the product backlog item
History - This field shows any changes made to the Product backlog item and by whom
Relative Value - This is the priority of this product backlog item, as defined by the business
Links - Allows you to create relationships between work items, for example you can link a Sprint Backlog item to it’s parent Product Backlog item.
File Attachments - Area you can upload associated documents (i.e. wire frames, user stories etc…) to.

 

Sprint Backlog Item:

The Sprint Backlog Item WIT represents the tasks involved in completing a Product Backlog Item. The Sprint Backlog Item WIT can represent a task, a bug or an impediment - they are defined using technical terminology, the estimated effort and work remaining values are both given in hours - because the task is now granular enough to be assigned a more accurate estimate. The complete list of fields for this WIT are listed below:

Sprint Backlog Item Work Item Type

Fields:

Title - Title of the Sprint Backlog Item
Estimated Effort - This is the initial estimate of the effort required to complete the sprint backlog item – usually measured in hours.
Work Remaining - Amount of estimated work left to be completed on the backlog item – usually measured in hours.
Sprint Number- This is the number of the Sprint that this Sprint Backlog will be completed in
Backlog Item Type - This drop down list defines whether the Sprint Backlog Item is a Task, a Bug or an Impediment.
Owned By - Person who has chosen to carry out this task
Current Status - Defines the current state of the Sprint Backlog item. The choices are:

  • Not Done - no work has been started on this Sprint Backlog Item
  • In Progress - work is currently underway on this Sprint Backlog Item
  • Deferred -work was started on this Sprint Backlog Item but has been halted. The item is deferred and will be worked on again in the future (most likely the next Sprint)
  • Done - Sprint Backlog Item is complete and production quality

Description - Description of the Sprint Backlog Item
History - This field shows any changes made to the Sprint Backlog item and by whom
Links - The Sprint Backlog item can be linked to the Product Backlog item. The linkage is two-way - links the Sprint Backlog item to the Product Backlog item and vice versa
File Attachments - Area you can upload associated documents (i.e. wire frames, user stories etc…) to.

 

So what do you think? Are these the fields you'd expect? Are we missing anything? I'd love to hear your feedback.

Published Thursday, October 27, 2005 10:15 AM by howard.vanrooijen
Filed under: , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

John Lawrence (MSFT) said:

I mentioned yesterday that Howard van Rooijen is working on Team Foundation process templates for Scrum...
October 27, 2005 3:34 PM
 

Jerrad Anderson said:

just curious, but seeing as team system has roles for everyone do you think your scrum plugin could involve more roles? i.e. developers testers and managers maybe?

Maybe a way to identify scrum masters and test leads.
October 27, 2005 4:03 PM
 

Johan Nordin said:

Is there are reason for not using the IterationPath for Sprint number?

There are a number of properties that is exkluded from the Product and Sprint back-log, such as Area Path, which might help to categorise the work items, BUT, I really like the idea of keeping things simple.

Is it possible to get the WorkItem types to test the template including states etc?
October 28, 2005 9:53 AM
 

howard.vanrooijen said:

Johan,

Yes the long term plan is to use the iteration path - but for the current build I'm working on I didn't have time.

We are a few weeks away from releasing the first beta (we want to be synchronised with Beta 3 refresh) - if you send me your contact details (via the contacts link) - I'll make sure we get you a drop ASAP.

Thanks for taking the time to comment.
October 28, 2005 10:44 AM
 

howard.vanrooijen said:

Jerrad,

We are supporting the roles defined by Scrum - Product Owner, Scrum Master and The Team (Developers, Testers, UE etc - Scrum does not differentiate between the roles as the team is expected to be cross-functional).

The process guidance that will come with the plug-in will go into this in more detail - but the Work Item Types (WIT) are generally related to the roles. The Sprint and Product Backlog Item WIT should be managed by the Product Owner and Scrum Master and the Sprint Backlog WIT should be managed by The Team (as it represents the tasks that they define, estimate and commit to complete).

Scrum teams are optimally around 7 people in size - so with this small a team do people really need to be told who the Tester / Product Owner / Scrum Master is?

I'll look into how we could add roles.

Thanks very much for the feedback.

Howard



October 28, 2005 11:14 AM
 

Chris Kinsman said:

Will you be making this scrum plugin available to the community? What are your plans in this area?

Thanks,

Chris
October 28, 2005 7:04 PM
 

howard.vanrooijen said:

Hi Chris,

I probably should have explicitly stipulated this in the post (I’ll highlight it in the next post in the series).

It will be available as a free download from www.scrum-master.com.

For the full press release take a look here:

http://www.conchango.com/Web/Public/Content/NewsRoom/PressReleaseDetails.aspx?PageID=270

Thanks for the interest and please contact me if you have any more questions.
October 29, 2005 12:38 AM
 

Jonathan Malek said:

November 2, 2005 10:07 PM
 

Patrick Altman said:

The more I read about Scrum, the more I am impressed by it's simplicity and it's power to transform development...
November 18, 2005 3:35 PM
 

Phil Scott said:

With the looming public release of Microsoft Visual Studio 2005 Team System, we are all hearing about...
December 17, 2005 12:53 AM
 

Phil Scott said:

With the looming public release of Microsoft Visual Studio 2005 Team System, we are all hearing about...
December 17, 2005 12:54 AM
 

Ryan said:

Is there a way to convert an existing project to use the Scrum process template?
March 30, 2006 3:40 PM
 

howard.vanrooijen said:

Ryan,

Not at the moment - although we are investigating how we could achieve this.
March 30, 2006 3:44 PM
 

John Staniforth said:

Hi,
just started using your SCRUM implementation for Team Foundation Server, thanks this is looking like it will assist us immensely. May I suggest that the units of measure might be shown as sometimes you state that hours are used and sometime days?
Thanks.
April 3, 2006 11:13 AM
 

howard.vanrooijen said:

We'll look into it.

There are only 2 different units - Product Backlog Items are estimated in terms of days and Sprint Backlog Items are estimated in terms of hours.
April 3, 2006 11:28 AM
 

rmokros said:

is this template available for download?
January 9, 2007 3:58 PM
 

howard.vanrooijen said:

rmokros,

You can download Scrum for Team System v1.1 from http://www.scrumforteamsystem.com/

January 24, 2007 8:33 AM
 

Jon said:

In the Product Backlog Item section you say:

- " Relative Value - This is the defined business value of this product backlog item."

- " Relative Value - This is the priority of this product backlog item, as defined by the business."

We are currently using this for story points (first definition as I interpret it).  But we have not clear cut way to prioritize the product backlog within the system.  Can you suggest something, or clarify the usage for this?

September 26, 2007 5:55 PM
 

Don said:

Hello Howard,

Some of my product backlog items are missing the value of Remaining Work, although the child sprint backlog items do have values in their Remaining Work. They don't add up to the PBI's Remaing Work. Where should I look to fix the problem?

Thanks in advance,

Don

May 27, 2008 7:58 PM
 

howard.vanrooijen said:

Hi Don,

you might want to check out the "Consistency Checker" tool:

http://scrumforteamsystem.com/cs/forums/1108/ShowPost.aspx">http://scrumforteamsystem.com/cs/forums/1108/ShowPost.aspx

If this doesn't help - post your question at the SfTS forums:

http://scrumforteamsystem.com/cs/forums/

May 27, 2008 9:08 PM
 

Don said:

"Consistency Checker" by SFTS only works with TFS 2005 not TFS2008. It doesn't help.

Thanks for your response anyway.

May 27, 2008 11:32 PM
 

Trafalgar said:

Hey--

I have recently come into responsibility for a MS TFS/Conchango system.

WI templates have been created, but I have a question about "time".

On our system SBI Estimated Effort is best guess hours; Total Effort is Actual hours; and PBI Work Remaining is best guess remaining hours.

Conchango Scrum indicates that Estimated Effort is best guess Days; Work Remaining in PBI is auto-calculated based on child SBIs. And I cannot find reference to a Total Effort.

Can someone help sort this out for me, please?

-Trafalgar

November 10, 2008 1:10 AM
 

howard.vanrooijen said:

Hi Trafalgar,

AFAIK “Total Effort” isn’t part of our default template. I expect that the template has been customised in order to track actual time spent on a PBI.

The default SfTS time fields are:

SBI:

               Estimated Effort (Est. Hours)

               Work Remaining (Hours until task completion)

PBI:

               Estimated Effort (Story Points)

               Work Remaining (Hours until story completed, sum of SBI work remaining)

November 10, 2008 3:40 PM
 

Charles said:

Hello Howard,

Do you know if Comchago will add a field in order to track actual time spent on a PBI.

Best,

January 11, 2009 1:14 AM
 

Ramunas said:

Is it possible to calculate estimated effort in PBI from linked SPI's, the same case as with work remaining, which is automatically calculated form linked work items?

March 12, 2009 9:18 AM
 

DP_Scrum said:

Not sure if this is a good blog for this Question but we had one about Tracking Impediments in TFS 2008:

There is no way tracking efforts spent on resolving impediments. Impediment work item doesn’t have a field to enter the effort. It makes it difficult to evaluate the impact of impediments on the project deliverables. Is there a way to quantify the impact of Impediments?

Thank You!

October 29, 2009 11:26 AM
 

howard.vanrooijen said:

Hi,

Probably best to post this on the SfTS Forum: http://scrumforteamsystem.com/cs/forums/

Thanks!

Howard

October 29, 2009 11:31 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit

This Blog

Syndication

News

This blog has now moved - please visit http://howard.vanrooijen.co.uk/blog for new content!
Add to Live.com
Powered by Community Server (Personal Edition), by Telligent Systems