What's in Product backlog?
What's appropriate to put into Product backlog? In order to answer this question, we first look at different views on Scrum.
Two views of Scrum
One is viewing Scrum as planning framework, then, PBI (Product Backlog Item) is the unit for work planning. The other is viewing Scrum as product development framework, then, PBI is the unit for product inspection and adaptation.
The different views lead to different thoughts about what are appropriate items in Product backlog.
What's in Product backlog?
With the view of Scrum as planning framework, everything that needs to be done can be put into Product backlog and planned in Sprints. This still makes sense until things not directly related to product come in, and some ought to be tasks in Sprint backlog. Some Product Owners mis-use Product backlog as a tool for execution. When ex-project manager takes the role of Product Owner, as they used to be execution oriented, this actually becomes a common pitfall. Over time, there is tendency to incorporate "how" items into Product backlog.
With the view of Scrum as product development framework, only things that help product inspection and adaptation are put into Product backlog. How valuable is it to inspect so as to adapt towards product vision and goals? Learning about the real customer needs is a valid PBI, as it helps move closer to successful product, assuming that it is validated learning. Prototypes and spikes are valid PBIs, as we build the product iteratively. Tasks are not, as they do not necessarily build working software and/or validated learning. Product Owners and great product managers use Product backlog as a tool for empirically developing a successful product. My colleague used Sprint goals to drive a new product development.[1] A series of Sprint goals are actually items in Product backlog. Over time, there is tendency to incorporate "why" items into Product backlog.
Product backlog at scale
When we look at two most popular scaling framework, SAFe and LeSS. They take different views for Scrum, thus, their guides on Product backlog are also different.
In SAFe, there's no Product backlog, but team backlog, program backlog and portfolio backlog. At team level, it's defined as pretty much standard Scrum, while the use of team backlog indicates that it views Scrum as planning framework. As the team may or may not be feature team, items in team backlog may or may not be product features. At team level, the focus is mainly on execution of planned work.
In LeSS, it keeps product focus and scales only teams. LeSS views Scrum as product development framework, thus Product backlog is still product backlog. Any PBI by any team can be inspected then adapted at product level. As LeSS requires that the majority of teams are feature teams, the focus is mainly on product inspection and adaptation on Sprint basis.
Conclusion
To me, Product backlog is the backlog for product. It's critical to understand what our product is, then we can use Product backlog as a tool to iteratively and incrementally build it.
[1] http://innolauncher.com/goal/
