Product Backlog Item (PBI)

Work In progress...

The Product Backlogs Items are requirements or ideas that can add value to a product being developed by the team, these elements can refer to features, research, technical debt.

The PBI should contains certain characteristics, a common practice on the Product Backlog management is the acronym DEEP, Detailed Appropriate, Emergent, Estimated and Prioritized, we will proceed to explain each of these concepts.

1. Detailed Appropriate: some of the backlog items may have a different level of detail, usually the ones that appear on top of the product backlog are more detail, because those items are the one that we will work first. After finishing the ones on the top, we want to refine the items as they rise to the top, to validate the backlog items that are not being worked are updated within the project requirements.

2. Emergent: as the project progresses and the team and Product Owner learn more about the product it might occur that some functionalities will not be required and the backlog items related to those items should be remove from the Product Backlog, also some backlog items could be updated and even we can create new ones. If this characteristic is showing in our backlog items is a sign for a healthy and functioning product backlog.

3. Prioritized: The product to-do list should be a priority list for the PBI, but not every PBI needs to be prioritized. I suggest giving priority to the publishing value of PBI. Exceeding this priority may waste energy, because too many changes may occur when the first version is released. Instead, prioritize new items as they appear, and save "one day" or "future release" items for later use.

Each of the PBI should have defined the next properties:

1. Description: must be concise and precise, usually has the user history format (As a “user “, I want “goal “so that “ result “), usually the Product Owner is the responsible to define the description.

2. Effort: the complexity that the product backlog item may present is estimated with a value, this value is defined through the Scrum Poker strategy, in which each member of the team decides how much effort is necessary to complete the PBI, in case there is no consensus on the value, the minimum and maximum values give their points of view and vote again until an agreement is reached.

3. Acceptance criteria: this are the conditions that a software product must satisfy in order to be accepted by a user, customer or interested party. An important fact is that it is a binary behavior: it is complete, or it is not. There is no concept of partially meeting an acceptance criterion.

4. Priority: prioritize product backlogs based on factors such as effort and feedback from Product Owner, customer, and development team, or even in combination.