Product Backlog Items
... you are building a Product Backlog from items that will drive your business.
✥ ✥ ✥
You want to best organize work to optimize the enterprise'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.
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.
Therefore: Create Product Backlog Items (PBIs) to represent concrete product increments that have value to relevant stakeholders. 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 help the Product Owner Team better do its work. A PBI can be anything that has potential value to a stakeholder.
✥ ✥ ✥
Make sure that the PBIs reflect any and all development dependencies between the work tasks necessary to deliver them.
PBIs tend to be focused toward the stakeholders, rather than towards the team. The team should manage its own work items as Tasks without undue interference or advice from the Product Owner, who has better things to do. So, for example, refactoring and bug fixing probably would not be PBIs for a software product. Sometimes, however, these items loom large enough to threaten the business in the long term. In an extreme situation the Product Owner may include bugs, technical debt reduction, and other traditionally inward-facing items on a PBI, because they have become large enough to merit business-level oversight. If the Product Owner is spending much time dealing with such issues, they should be viewed as impediments. See also Illegitimus Non Interruptus.
PBIs should usually not be work items or tasks: that confuses the value delivered with the mechanism used to create that value. This kind of confusion can cause the business to lose its external focus on the market.
You can order PBIs on the basis of ROI. You can do this either on the basis of the individual ROI of relatively independent PBIs (High Value First) or on the basis of overall, long-term ROI (ROI).
Author: Jim Coplien