Work Item: Product Backlog Item
The Product Backlog Item, or PBI is the Work Item Type (WIT) that holds the description of the "Product Increments" that your Scrum Team will be building.
Considered together as a whole, these PBI's are referred to as your "Product Backlog".
The PBI form is broken up into three primary sections, which are intended to form a left to right workflow as you process your PBI's from being an idea through to a completed increment of functionality.
The Title is the handle to the PBI. Ideally this should be descriptive text, although some folks who like to keep a lo-fi task board and backlog in parallel with their TFS instance sometimes find that numeric codes such as "PBI026" are more convenient.
The fundamentals section hold the bare basics of any Product Backlog Item and represent the first things you should be thinking about once you've given your PBI a name.
The first fundamental is Business Value. This is an integer value that you assign to your PBI, in order to indicate the value that this PBI is expected to deliver once it is implemented.
"Business Value" can take many forms, some of the most common include: making money, saving money or increasing market share. You can also assign and represent your business value using common techniques such as Priority Poker or Theme Screening.
For the purposes of calculating ROI, PBI's with higher value to the project should be given larger numbers regardless of the method you use to calculate your Business Value.
Story points indicate the "size" of your Product Backlog Item, and thus the effort required to get the PBI into production.
The Story Point series is commonly held by the Agile Community as 0,1,2,3,5,8,13,20,40,100 and is considered to be a relative measure of size, not an absolute measure.
But you may use any values that you find useful.
Story Points are typically assigned through the process of Planning Poker, which is an agile estimation technique that uses special playing cards.
These days, you can obtain Planning Poker cards from almost anywhere, but the EMC Consulting variety are (at time of writing) the only Microsoft Surface compatible Planning Poker Cards on the market.
Return On Investment (ROI) is a calculated field, which simply divides the business value by the story points to give a ration indicating the relative amount of benefit you will get for the predicted effort your team is going to expend.
The ROI is a very useful figure to assist your Product Owner in prioritising the work and is calculated for you automatically by the template.
Feature Scope is the Scrum for Team System name for "Area Path". We recommend that you use this field to track Epics and Themes, or implement Story Mapping.
Once you have the fundamentals of your story in place, you can then schedule the PBI to be implemented.
Scrum for Team System provides two fields to assist you in doing this.
Delivery Order is another integer field, that can be used to reflect the order in which you are actually intending on delivering the PBI's. Delivery order is also a useful field for external tools to use to sort & display your PBI's and can also be used in conjunction with Excel to record a desired sort order.
Historically the most common use of Delivery Order is sequential integers, although you need not follow this convention. If you are using Story Mapping, then you may use it to reflect your design fidelity.
If you are using a linear backlog, then this field could be considered as the traditional Scrum "Priority Order" field.
Due to the way in which TFS process templates work, planning scope is actually more important to the scheduling of your PBI's than the delivery order or indeed any other field.
Delivery Order is advisory, informational & optional, whereas Planning Scope is mandatory and overrides any other field. There is nothing to stop you, apart from convention from placing low priority items in near term planning scopes.
The planning scope is not entered directy, but rather selected from a drop down box from a pre-created Planning Scope Tree.
It's good practice to move your PBI through the Planning Scope as you continue to develop it.
NOTE: For users familiar with previous versions of the Scrum for Team System template, it's important to take note that the Iteration Path format used by v3 differs significantly from that used in version 2.2 - not only is the format itself different, but it is now supported by three WIT's - the Release, the Sprint and the Team Sprint - each of which is essential for correct operation of the template. Because if this additional complexity, we recommend that you set-up your project with the ScrumMaster's Workbench, which makes creating the Planning Scope for you project extremely easy.
There are two fields in the tracking section, but most of the time these fields are automatically set for you by our Event Service and you need not, and should not set these manually, unless Descoping, Deleting or Deprecating a Product Backlog Item.
The field reflects the current status of the PBI in question throughout it's entire lifecycle. In the majority of cases, you need never set this field manually as the Event Service will update it based on state of other Work Items.
For more detailed information each of the States, click on the links at the upper right of this page.
The Work Remaining Field is a calculated field, which adds up the Work Remaining (in hours) on each of the linked Sprint Backlog Tasks that are linked via the Implements link to this Product Backlog Item.
If you are not estimating your tasks in hours, this field will then represent how many undone tasks are remaining to be completed on this PBI.
The named link types in VS2010 have allowed us to produce a far more expressive and useful template. Nowhere is this more apparent than in the tabs which hold the collections of linked work items.
For a good overview of how other WIT's link to the Product Backlog Item, see the following blog post:
If you need to add more detail to your PBI that is provided in the Title field, then place that information here.
A Note on the User Story 'Format'
User Stories are a very popular format and we have provided one of the popular User Story template texts as a placeholder.
It's a common misunderstanding however that Product Backlog Items have to be in User Story Format. Some people have taken this misunderstanding so far, that they call all backlog items on all Scrum projects "User Stories".
The correct Scrum Terminology is "Product Backlog Item", not User Story and Product Backlog items can make use any format that works for you and your project.
It's an even more common misunderstanding that a User Story is writing your requirement in the "As a <role> I want to <ability> so that <benefit>" format. Whilst popular (too popular perhaps), this isn't true.
There is nothing wrong with this format, unless you are spending hours trying to shoehorn your requirements into that structure as if it was some kind of Sūtra with magical properties.
The more important rule of thumb to follow for User Stories is to understand that they are made up of three parts:
The Title & Description fields in the PBI WIT could said to comprise the "Card" component of the User Story.
The Conversation is up to you, but it is a reminder to not rely solely on the "Card" but rather, to have a conversation between the Product Owner who knows what they want, and the team, who knows how to build it.
Once you've had this Conversation, you can then record the output.
What you are looking for most of all is an output that represents a common understanding of "How will we know when we've done this for you?" - and Acceptance Tests have proved themselves to be by far the best mechanism of doing this. If you link your Acceptance Tests to your PBI, they'll all be at hand the Tested By tab, as described below.
The History tab shows you the all the changes that have been made to this PBI WIT since it was first created. This includes changes made by users and also changes made automatically by our Event Service.
Event Service changes will be marked as either from the "Scrum Transition Service" or the "Scrum Aggregation Service"
The Impeded By tab lists all the Impediment Work Items that are linked to this Product Backlog Item WIT, via the Impedes link-type.
One of the best new features of Scrum for Team System Version 3, is the ability to link Impediments to the PBI's that they impede. This allows, ScrumMasters, Team Members and Product Owners alike to instantly get access to project critical data.
Impediments may impede more than one Product Backlog Item, or none at all, but in that case, what are they impeding?
The "Conditions of Acceptance" tab from Version 2.x has gone, and it has been replaced by the Tested By tab.
By taking advantage of the great new features in VS 2010, the Acceptance Tests for your PBI's are now fully fledged Work Items, but you should generally still consider them as part of the Product Backlog Item, especially if you are using User Stories. See the above side note on User Stories for more detail.
The Tested By tab shows you at a glance the Acceptance Tests for this PBI, as well as their current state - which ones are passing, which are still to be implemented and which ones have been run but failed.
Note: Acceptance Tests states can also be controlled by Bugs. If you have failing Acceptance test, and can't figure out why, then it's most likely somebody has raised a Bug against your Acceptance test which needs to be fixed before the Acceptance Test will pass.
This tab holds the list of all the Sprint Backlog Tasks that have been linked to this Product Backlog Item (and by association are the tasks that the team needs to perform in order to complete this Product Backlog Item)
Sprint Backlog Tasks represent the "work" that needs to be done to create the functionality that the Product Backlog Item is requesting. This tab shows a quick list of the state of each Task along with who is currently working on it. The sum total of the hours or tasks remaining uncompleted in this section is tallied up under working remaining in the "Tracking Box" in the upper part of the PBI form.
This tab holds a list of all the other work items that are linked to this PBI, regardless of link type or Work Item Type.
This tab allows you to attach files to you work item. This is particularly useful for attaching examples, screen shots, scamps and wireframes or any other file that team members would find useful when implementing or understanding the Product Backlog Item.