Introduction

Scrum is an iterative software development process. In an iterative process, a product undergoes many releases and each release adds value to the product. In Scrum, each release is divided into sprints. Sprints are fixed durations, two to eight weeks, in which all development activities take place.

Each sprint produces a potentially shippable product that contains features, called Product Backlog, which meet customer expectations. In this article, we will see details of Product Backlog with respect to Scrum in Team Foundation Server 2010.

Roles

Scrum has a very simple team structure that involves just three roles. This structure generally doesn't translate to an organization or a reporting structure within a company, but it clearly defines who does what on the Scrum team. These are the three roles:

Product Owner can be a leader in the user community, such as someone from marketing, a business analyst within the IT arena or any other individual who can effectively communicate business needs. They determine what features go into the product, is the voice of the customer, is responsible for ensuring that product features meet customer expectations and is always available to meet directly with the development team to discuss and review features.
Scrum Master is responsible for tracking project status and coordination through release.

Team productivity. Removal of impediments to progress. Defines the sprint duration (generally two to four weeks).

Runs the daily stand up meeting. Helps to keep all team members working productively.

Team Members are responsible for building and testing high quality software. Has skills in software engineering, software architecture, business analysis, software testing, database tuning, IT operations, user experience, and user interface design.

Scrum Artifacts

An artifact is an object created for a practical purpose. Scrum has four artifacts:
What is Product Backlog

In this article we are going to see Product Backlog in details.

The product backlog is the list of features that the product owner believes will make a great product.

Product Backlog defines the full product; the Product Backlog Items (PBIs) define the individual features. Before the project begins, and before the team is assembled, the product owner meets with customers to develop a deep understanding of their needs.

The product backlog: is the sole input queue for the team. Has one set of items before the first sprint, and it has a Very different set with every sprint afterward. Is never static and is never complete. Grows as customers see the product and have more suggestions.

Releases and Sprints:

Release planning meeting:
Sprint planning meeting:
Please refer diagram below:

It shows the flow of new features into a product. It begins with the product manager translating customer requirements and desires into a list of product features that can be built by the team. This list is called the product backlog.

A Scrum team is organized to efficiently build a product in small sprints of activity. The product owner prioritizes the product backlog and identifies a subset of related features that can be implemented in a sprint. Each sprint has its own list, called a sprint backlog.

Each sprint begins with a list of features to build. Each sprint ends with most, but not all, of the features complete. The incomplete items are added back to the product backlog for inclusion in another sprint. After a few sprints (typically between 3 and 10) the team is ready to release a version of the product. It releases the bits, distributes the product to customers, gets feedback, and begins building the next version.

PBI1.gif

Microsoft Visual Studio Scrum 1.0 process template
Work Items in TFS 2010

Project data in TFS is stored in artifacts known as work items. Work items are database records that track the definition, assignment, priority, and state of work for your team. The Microsoft Visual Studio Scrum 1.0 process template includes seven work item types:
Creating Product Backlog Item (PBI) in Visual Studio

The product backlog consists of product backlog items (PBIs). Each PBI is an individual requirement that is small enough to build and test within a sprint. PBIs are generally user centric requirements, such as "manage the online shopping basket" but they can also be IT - centric, as in "verify that credit card data is not persisted in the database".

The product owner is responsible for the PBIs, from defining them in enough detail that the team can build them to including acceptance criteria so the team knows when the PBIs are done.

To document a PBI in Visual Studio, you select Team >> New Item >> Backlog Item.

PBI2.png

PBI3.png

Following are the fields:

Title: Brief description of the PBI. The title of a PBI should represent the intent of the PBI.

Iteration: Indicate the sprint in which a PBI is implemented. When you first enter a PBI into TFS, iteration defaults to the current project, meaning that it's not yet scheduled for a sprint. During the sprint planning meeting, when the team commits to implementing a PBI, you set this field to the iteration representing the sprint.

Assigned To: Indicates the owner of a PBI. The product owner who's assigned to the PBI is responsible for answering questions and providing details about the PBI. This person is also responsible for verifying that the PBI meets acceptance criteria before the team finishes the sprint. When a PBI is first created, the Assigned To field defaults to the user entering the PBI, so it's best to set it to the product owner at that point.

State: Use the State field to track the current state of a PBI.
Reason: Reason is a read - only field that is predefined based on the state and transition of the PBI.
Backlog Priority: Used to determine the position of the PBI on the product backlog. New PBIs default to a backlog priority of 1,000. This field represents an item's location in the backlog, not its business value. It indicates when the PBI should be scheduled, relative to other items on the list.

Effort: Used to track the estimated effort required to implement a PBI, relative to other PBIs in the release. Relative is the operative word here, as the effort is not in terms of hours or days. Rather, it's a just a number used to compare the relative effort required for PBIs.

Business Value: Used to track the amount of business value delivered by a PBI. You should choose a number between 1 and 100 to represent the amount of business value that implementing the PBI will deliver to your customers. Higher numbers imply greater business value. A PBI with a low business value and a high effort estimate probably won't get scheduled into a sprint and will remain on the product backlog.

Description: Used to provide a detailed description of a PBI. This is where the product owner describes what the feature does and who needs it. If you're defining PBIs via user stories, then this is the written record of the feature.

Acceptance Criteria: Used to provide a bulleted list of criteria a PBI must meet before it will be accepted as done. The product owner defines the acceptance criteria either when initially creating the PBI or when the PBI is added to a sprint. It's critical to have sufficient information in this field for a PBI because these are the criteria against which the team will build the feature during the sprint.

Conclusion

In this article, we have seen that the product backlog is the list of requirements for the system. It is the central focus of a Scrum team, representing the features that the team will build into the product. The product owner defines and prioritizes the PBIs. Each PBI stores the details of one product feature. It describes its business benefit, test cases, and acceptance criteria.