Comfortably Scrum: My Common Product Backlog Work Item Customizations

For the last half of this year I have spent the majority of my time helping various clients adopt Scrum and Agile engineering practices using Visual Studio Team System and Team Foundation Server. After initial Scrum training and an overview of TFS, we will customize the implementation to fit each company's individual needs. I am a big fan for Conchango's TFS process template for Scrum and their work item template for Product Backlog items is the template I extend the most. Here are some of the most common changes and additions I make to this item for my clients.

First I change few of the labels for the standard fields from the Conchango template:

Business Priority is changed to Business Value since the word "priority" has a certain connotation of order. I also implement a SuggestedValues rule with values ranging from 100 to 1000 with increments of 100 (100, 200, 300, etc.).

Estimated Effort (days/story points) is changed to just Story Points since I really encourage teams to not use days or hours when estimating the Product Backlog. I add a SuggestedValues rule to this field with the Agile standard of the Finbonacci sequence variation (1,2,3,5,8,12,20,40,100). Some clients use the planning poker cards from Crisp, but I do not include 0, 1/2, ?, or the Coffee Break card.

I also change the description on the Conditions of Acceptance section to include "or How To Demo Steps" since I really like using this technique over just a bulleted list of acceptance criteria.

I also add two new fields:

Return On Investment which is a read only field calculated by dividing the Business Value by the Story Points. We use this as additional perspective when ordering the Product Backlog. The value is updated by a web service created using Howard van Rooijen's project template for TFS event subscription end points.

Product Backlog Type which is used many different ways depending on your Agile tool or general philosophy. My version has three allowed values:

• User Story which is exactly what it sounds like. All these entries must fit the user story format.
  


• Technical Requirement which is for any behind the scenes work like refactoring, building supporting components with no UI, etc. This helps identify which items require functional tests to be created (meaning a User Story) or those that just need to be regression tested with the current suite of tests.
  



• Epic which is used for placeholder entries. Some people like to use TFS Areas for this but I prefer to put it at the Product Backlog level. It allows stakeholders to throw pie in the sky ideas on the backlog. Our rules specify that an Epic is not estimated, is always last in delivery order, and can never be added to a Sprint until it is broken up into acceptable User Stories with a Story Point value that can be done in half a Sprint.

I also add some new work flow steps:

Ready For Test is something the Conchango template puts at the Sprint Backlog level and I prefer to have this measured at the Product Backlog level. There is some contention on this even on the Conchango forums. My thought is that a task like "Create class to hold search criteria." cannot be tested but its corresponding User Story ("Search Online Catalog") can be.

Failed Test and Passed Test are two optional steps I sometimes put in to follow Ready For Test. This depends on how integrated the testers are with the development team. If they are very integrated and the team is good with simply communicating failed and passed tests verbally or via email then these can be left off. I have had less integrated QA teams that were also not co-located with the team and we found these steps necessary to keep up with test results.

And finally I organize the form a bit to keep it symmetrical and grouped a bit more clearly.

These changes are not necessarily a good fit for every team and I really try to understand the level at which each client can adopt the Scrum processes before we run head first into customization. I have found these changes to bring value to the process for the majority of time.