The document discusses notes on creating an effective product backlog, including breaking backlog items into small, testable pieces that are clearly defined and immediately actionable to developers, with estimates provided by the implementing team. It cautions that a poor product backlog can reduce team performance by at least 50% and result in more unused features and lower quality, citing a source that estimates overall performance may be only 17.5% of what it could be with an ineffective backlog.

1. Notes to Myself
PRODUCT BACKLOG

2. Notes to Myself: Product Backlog
 Broken down into small  Testable (i.e., acceptance
pieces tests are clearly defined
 Clear to the developers that determine whether
 Immediately actionable
the backlog item is done)
 Estimated in points by
the team that will
implement it

3. Notes to Myself: Product Backlog
 Jeff Sutherland: “Poor product backlog will typically
reduce team performance by at least 50%. Complicating
the problem, customers rarely or never use 65% of
features that are created on average worldwide. Poor
product backlogs will have more unused features, as well
as poor quality in the features that are used. If you
develop less than half as fast as you could and 65% of
what you build is waste, your performance is only 17.5%
of what it could be.”