The Agile Product Backlog consists of collections of items that add value to the Business Domain.

These items have been defined by the Business Team as Business User Stories with Acceptance Criteria.

The list below contains the most popular types of Agile Product Backlog items but anything that can be documented that could add value to the engagement is a candidate for a Backlog Item.

A List of Common Agile Backlog Items:

Business Team Application Features – Business User Stories with Acceptance Criteria that have been created and prioritized by the Business Team.

These Product Feature Requests are delivered to the Architect Team by the Product Owner after being added to the Agile Product Backlog.

Architecture Team Feature Scenarios – Business User Stories with Acceptance Criteria received by the Product Owner are transformed into Behavior Driven Design (BDD) Development Feature Stories with Acceptance Criteria Scenarios for Domain Model development during an upcoming Sprint iteration.

They are a Technology representation of their “Parent User Story”.

New Product Features – The Business Team request for a new application feature.

There is really very little difference between a Business Team Application Feature and a New Feature.

The main distinction is that a New Feature may have a relationship to a developed and delivered Application Feature that is already deployed to Production.

This relationship must be known as the New Feature may have Responsibilities and Dependencies on the existing feature.

Production Bugs – Application issues that are reported after an application has been deployed to production are “Bug Fixes”.

These issues are primarily reported by the User community.

These Bug Fixes are referred to as Production Bugs.

In the eyes of the User Community there is very little difference between a New Feature and a Production Bug Fix.

These items are treated as New Features by the Product Owner and scheduled in an upcoming Sprint in the same fashion as any other Sprint task.

Production Bugs are processed the same as QA Bugs.

A separate QA Bug Tracking and Management System are generally employed to manage QA Analysts discovered issues that do not meet the QA Objectives defined by the Acceptance Criteria Test Suite by the QA Team.

Production Bugs sometimes are managed in this tool but it is not recommended as the paradigms of the two are quite different.

Technical Requested Work – These Backlog Items are assigned to the Network Infrastructure Team as support items for the engagement.

These items include Development Tools, Upgrades and Updates, Service packs, Operation System updates and New Applications.

They can also be required Performance Enhancements and New Application and Database Servers required for the development and management of the Agile Sprints.

Proof of Concept Technical Work – On User Stories were the Risk Factor of “x5” has been applied are added to the Backlog as “POC Work”.

These items require a Proof of Concept before they are available for a Sprint iteration.

Proof of Concept work requires that validation of the design concept is completed and the User Story Points are updated with the knowledge gained.

The updated Acceptance Criteria Scenarios are then treated as any other Backlog item for development.

Technical Debt Code – When it becomes necessary to “Borrow on the Technical Debt Credit Card” these items are placed in the Backlog for prominent discovery.

These items are not prioritized upon entry.

Technical Debt is a metaphor that is based on the financial concept of using credit cards to buy items that you cannot really afford to pay for with resources you have already earned.

In the course of Sprint development, when Technical Debt is discovered, and cannot be paid off at that time, add a Task Assignment to the Backlog as Technical Debt.

By “Running it up the Flagpole” you remove Technical Debt from the deep dark corners of development and bring it into the “Light of the Development Process”.

By creating a Sprint Development Task assignment process that assigns Sprint Tasks only to the Wednesday of the last iteration week you create a development environment that supports two days per developer to pay down the Technical Debt.

This process also creates headroom for a higher degree of Sprint Task completion success.

The Scrum Master, with the Product Owner, can assign the “Low Laying Fruit” of Technical Debt.

This creates a dynamic in the development community that supports Technical Debt, when required, and prevents the cost of Technical Debt from becoming out of control.

Research Knowledge Acquisition Projects – These items are entered for studies required for gaining Technology knowledge.

These studies support gaining knowledge on the latest Best Practices, Technologies and available new products that could support the current engagement.

These activities are prerequisites for Proof of Concept initiatives.

The Christmas List – These backlog items are “Would Be Nice to Have” development items.

These items are not prioritized upon entry.

The Christmas List items relative value can change at any time during the engagement.

These Backlog items act as reminders of ideas that more than likely surfaced during Technology or Business meetings discussion and were by the Product Owner for Backlog archiving.

The Backlog Archive – These backlog items are “Not Require Now” development items.

These items are not prioritized upon entry.

The Backlog Archive items are similar to the Christmas List items except they generally become prioritized sooner due to requirement changes within Business Cases.

The Product Owner enters the prioritized item into the Agile Backlog.

There are some Agile Backlog item types that are not prioritized upon entry.

The item types not prioritized are:

1. Technical Debt Code
2. Christmas List Items
3. Archived Items

All of the items need to be reviewed on a regular basis, generally weekly, and assessed for their current relevance for the engagement.

The team determines which items they can successfully complete during the upcoming Sprint iteration.

The selected Agile Backlog items are moved from the Agile Product Backlog to the Sprint Backlog for development consideration.

The Sprint Planning team, generally the Scrum Master, Product Owner, the Architects and Designers along with the Development Leads detail each Product Backlog item into one or more Sprint backlog tasks so they can more effectively share development work during the new Sprint.

Generally the team begins at the top of the prioritized Sprint Backlog and selects the high-priority items they feel they can complete.

In practice, it’s not unusual to see a team select, for example, the select the top five items and then two low laying fruit items, from lower priorities on the list, that are related with the selected five.

This process creates a methodology that can improve the documented success of a completed Sprint by choosing items that have little risk of failure.

The Product Owner selects the items for upcoming Sprint.

The selected items are delivered to the Sprint Planning meeting for consideration in the upcoming Sprint.

The Sprint Planning team selects the items for upcoming Sprint from the delivered Agile Backlog items delivered by the Product Owner.

The selected items are delivered to the Sprint Planning meeting for consideration in the upcoming Sprint.

The Sprint task assignment process determines which items, delivered by the Product Owner, can be successfully completed.

Estimates the development time of each selected item is completed and a Developer is assigned.

The estimated tasks are accepted and signed off on by the assigned Developers for the upcoming Sprint iteration activities.

The Agile Backlog items are moved to the Sprint Backlog during the Sprint Planning session of an upcoming Sprint.

The Scrum Master owns the Sprint items with the Product Owner.

The Architect Team is responsible for the Designs and assignments of the selected items for Sprint development.

The Scrum Master, with the Product Owner, is responsible for returning an item to the Agile Backlog in the case of a Block due to insignificant knowledge about a particular Backlog item.

These items should be addressed at the next Sprint Planning session and placed back into development if the block can be resolved.