Aren't Product Backlog Items just User Stories?

Are Product Backlog Items the problem?

As a <>, I want <> So that <>.
— https://en.wikipedia.org/wiki/User_story

In nearly every Certified ScrumMaster (CSM) class, we have face template-zombieitis. This is the condition caused by the User Story template.  User Stories are not required in Scrum nor are they one of the Scrum artifacts. One only has to read the official Scrum Guide to validate this: https://www.scrumguides.org/

To be fair, User Stories were never meant to cause the template zombie condition. Just like Product Backlog Items, they were intended to be placeholders for conversations that were needed, or could reflect details of conversations that were already held. Somewhere along the line people seemed to forget this and began just trying to make stuff up to satisfy every field in the template, skipping the most important part:  the Conversation.

So just what is a product backlog item in the Scrum framework? One of the Scrum artifacts is the Product Backlog.  A Product Backlog Item, or PBI, is similar to the intent of the user story. It was a place to note conversations that needed to be held with the Product Owner and anyone else necessary to flush out more information about the item. As conversations are held, results of those conversations can be added to the PBI in plain old words. No prescription necessary!

As noted in the Scrum Guide:

  • PBI’s can represent considerations, questions, features, functions, requirements, enhancements, or fixes that constitute the changes to be made to the product in future releases.

  • Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done"

  • Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion

  • Higher ordered Product Backlog Items are usually clearer and more detailed than lower ordered ones.

product-backlog-items-displayed

Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through Refinement activity lead by the Product Owner with contributions by the Development Team prior to Sprint Planning. If a PBI cannot get to Done in a Sprint it may be split into smaller items during Refinement.

If you're ready to learn more- checkout Christian's upcoming CSM class here