Product Backlog Item

... you are building a Product Backlog from items that will drive your business. The Vision is in place and the Product Backlog may contain early informal notions of market releases or Sprint Goals.

✥       ✥       ✥ 

You want to best organize work to optimize the product’s ROI (Return on Investment). Scrum focuses a lot on how to organize work, and it’s obvious that “doing things right” contributes to a solid ROI. However, ROI may be even more closely linked to stakeholders and to “doing the right thing.”

More broadly, ROI is a result of adding value to stakeholders. An enterprise has many stakeholders: customers, end users, stockholders, designers, architects, developers, and testers, each of whom contributes to an overall sense of value and stands to benefit from the ongoing creation of Product Increments.

An ideal system increases value for all of the stakeholders, rather than benefiting one at the expense of the other. While everyone may have to give something (time, money, work), we want to achieve the paradox that everyone gets more than they give — or, at least as reduced to cynical terms, that everyone gets as much as they give.


Create distinct specifications of changes and additions to the product, called Product Backlog Items (PBIs), that together form the Product Backlog. Each PBI describes something that the Developers can develop and deliver to add value to relevant stakeholders when Done. The most common stakeholder is the market, or its representative — the Product Owner. However, a PBI may describe work that reduces cost to the enterprise or reduces effort for the Development Team, or a tool that helps the Product Owner Team better do its work. A PBI can describe anything that has potential value to a stakeholder.

A PBI should have a name or other designation that helps relevant stakeholders crisply recall what the deliverable encompasses. A good PBI captures the stakeholder-facing decisions that the Product Owner has taken, or agreements that the Product Owner has made with the Developers, that should be written down to avoid being forgotten. A good PBI is annotated with development estimates provided by the Developers who are to implement it, as well as notes about the PBI’s contribution to ROI.

The PBI is the focal point of Scrum deliverables. The lifetime of a Scrum deliverable starts with the Vision, which is broken down into Sprint Goals that correspond to Product Increments. Those Product Increments are broken down into PBIs, which are the most granular unit of delivery in Scrum. A PBI is brought to a status of Ready, and drives the design of the solution described in the Developers’ work plan, the Sprint Backlog. PBIs that achieve the stature of Done are delivery-ready.

✥       ✥       ✥ 

A PBI is usually one piece of a larger Product Increment, and the focus of the best PBIs is on a product solution that lies in the Product Vision rather than on the requirements behind that contribution to the increment. The requirements behind the deliverable will be discussed face-to-face as the Scrum Team makes the backlog Ready. The team and other stakeholders can use user stories, story boards, interaction diagrams, user narratives, and whatever tools they choose to shape a Product Backlog Item, but these artifacts in general are not themselves effective PBIs. For example, there may be many user stories for a single deliverable, each from a different stakeholder, that expresses the need and motivation of that stakeholder with respect to that deliverable. Yet it is the deliverable, and not its facilities, that should stand as the unit of administration, estimation, and delivery in Scrum — and the PBI represents that deliverable. The Scrum Team discusses requirement details face-to-face as they build a Refined Product Backlog and as they prepare for the Sprint at hand in Sprint Planning. So a good PBI represents a set of requirements rather than being a mechanism to communicate requirements. That said, the PBI can serve as a home for details about scenarios, properties of size or weight or speed or time, that otherwise may be forgotten. And though a good Product Backlog Item lives in the solution space rather than in the problem space, it falls short of specifying how the solution will be implemented and delivered.

While a PBI is a written artifact that appears on the Product Backlog, much of the information passed from the Product Owner to the Developers occurs verbally in Scrum planning events. A question-and-answer form of exchange, after an initial presentation by the Product Owner, is totally appropriate. A common pitfall is for the Product Owner to instead turn a PBI into a comprehensive document that developers can read to minimize the amount of interaction the Product Owner will need with the Developers. As a rule of thumb, PBIs should start lightweight and grow in detail and specificity as time progresses. The PBI may nonetheless carry detailed market information that will be important to realize the PBI (such as detailed response time requirements, or limitations on size or weight), because such information reflects a Product Owner or team decision on the nature of the deliverable.

The team should give special attention to PBIs near the top of the Product Backlog, which will soon be developed. The Product Owner and Developers should discuss these to the point where Developers view them as Enabling Specifications.

Make sure that the PBIs reflect any and all business and development dependencies between the work tasks necessary to deliver them. For PBIs that depend on a particular calendar date (for example, to be started after taking delivery on some part that has been ordered with a promised delivery date) use Fixed-Date PBI.

While Scrum does not stipulate any format for PBIs, there must be a caution here about using user stories. User stories present a quick summary of some what for a PBI but much of their value comes in identifying the stakeholder (who) and the stakeholder’s motivation (why). User stories are in the requirements space. One PBI may satisfy the requirements germane to several user stories. From the perspective of release management the elements of the Product Backlog are deliverables to be developed rather than the requirements that these deliverables satisfy. The team may use any format by which stakeholders can easily recognize or envision a deliverable to which they can relate.

PBIs that are broken down to about 10% of a Sprint delivery usually yield the best estimates; get to Small Items with approaches such as Granularity Gradient to avoid the waste of breaking down the entire backlog. The Development Team should estimate all PBIs (Pigs Estimate), with the best practice being Estimation Points.

PBIs should usually not be used to direct inwardly-focused work items or tasks: that confuses the value delivered with the mechanisms used to create that value. Such confusion can cause the business to lose its external market focus. PBIs tend to be focused toward the stakeholders, rather than towards development. The Development Team should manage its own work plan, or Sprint Backlog, without undue meddling from the Product Owner. Some items, like cleaning the shop floor, daily machine maintenance, or refactoring code, are so routine that they are not even explicit in the work plan let alone directed at the business level. Other internal-facing work items such as, for example, testing and writing purchase orders might be explicit in the work plan, but are unlikely to explicitly appear as PBIs. Sometimes, however, these items loom large enough to threaten long term value: for example, cumulative effects of ignoring daily machine maintenance, or Good Housekeeping, may leave a work environment that is unsafe or inefficient and which begs a sizeable cleanup effort. In such exceptional situations the Product Owner may include bugs, overdue machine maintenance, technical debt reduction, and other traditionally inward-facing items in PBIs because they have become large enough to merit business-level oversight.

On the other hand, while most PBIs relate to the Product Increment, a PBI can certainly describe any deliverable that increases stakeholder value. Even internal documents such as engineering diagrams can be viewed as PBIs because they add value for the team, which in this case can be viewed as a stakeholder; external user manuals will certainly be developed in response to a PBI. PBIs should nonetheless still focus on what, when and who rather than how. If the Product Owner is spending much time dealing with the how of development rather than the what, when and who, then the team should seek out and address the underlying impediments. See also Illegitimus Non Interruptus for a description of an advanced approach to use PBIs to bring important concerns outside the Product Increment itself into sharp focus.

An advanced use of PBIs is to elicit process improvement work that requires work by the Developers during the Sprint. See Scrumming the Scrum.

When completed at the end of the Sprint, the product contribution driven by a Product Backlog Item must meet the Definition of Done.

You can order PBIs on the basis of cost and ROI aspirations. Even with all other things being equal, changing the position of a PBI in the backlog can change its contribution to ROI, e.g., because of alignment to a season or to the market. You can order the Product Backlog either on the basis of the individual ROI estimates of relatively independent PBIs (High Value First) or on the basis of overall, long-term, integrative ROI.

Picture from: bikeriderlondon, image id:144640766, (