Scrum Rules: Product Backlog Items Are Invitations to Conversations

Product Backlog Items are brief descriptions of a feature or function. Usually they are short enough that they could be hand-written on a small note card. This brevity is meant to be just enough information so that the Product Owner and the team can use the PBIs as invitations to conversations.

The resulting conversation (ongoing, evolving and involving the whole team and stakeholders) and the shared understanding that comes from that conversation is where the real value of the PBI resides. Part of the conversation occurs when the Product Owner initially writes the PBI so that the team can estimate the effort of building it. Part of the conversation is the actual work being done during a Sprint. Another part of the conversation is during the Sprint Review when stakeholders see the results of the team building the PBIs. If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution. The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities. If we lock them into a set path, then we are literally turning them into cogs in a machine to spit out specific code. PBIs that are invitations to conversations allow them the flexibility to figure out how to solve the problem by engaging in a conversation on what is needed.

The first step in creating a PBI that is an invitation to a conversation (vs. a detailed specification) is simply to write it as briefly as possible on a physical note card (even if your eventual tool is electronic). Try to write the feature or function description in five words or less. Once the Product Owner has that card written, the second step is to take it to the team. The team can choose to look at it at any time after the Product Owner brings it to them, but it should be sometime during the Sprint when the new item is written on the card. That first conversation then, is to simply ask the team “from these few words, can you understand what I mean at a high level?” They may ask some questions at this point, but it is not necessary to capture all the details. Instead, as soon as the Product Owner feels they have a basic understanding of what is meant, the Product Owner should ask the team to estimate the item. This usually brings about a much deeper level of conversation but can still be as brief as just a few minutes. The Product Owner may want to write one or two important notes at this point, but it is critical to avoid writing any details of prospective solutions on the card! With the team’s estimate on hand, the Product Owner is welcome to position the new Product Backlog Item on the Product Backlog. At the point where it is at the top of the Product Backlog and the team is doing Sprint Planning, the third step begins: detailed analysis of the technical solution for the Product Backlog Item. Avoid writing down these details unless they specifically relate to the kind of high-level testing that might be required: the acceptance criteria for the feature or function. And, just as a reminder, don’t write any technical solution details on the card! The fourth step comes as the team starts the work of the Sprint. The team will work with the Product Owner to capture detailed specifications… not as documentation, but rather as executable acceptance tests. This requires, at a minimum, a testing tool that allows for basic scripting, but may be more involved depending on the technical platform you are using. For web-based work, Selenium is a great tool and browsing their online documentation will give you a good idea of what sort of things to look for in other tools. These conversations are much more in-depth and constitute an important part of the work of the Scrum Team. The fifth and usually final step is the conversation that occurs during the Sprint Review Meeting when the team demonstrates the work. The Product Owner, and other stakeholders will examine the results and provide feedback to the team. This feedback may be captured as new Product Backlog Items, defect reports or the like and may then lead to new conversations. Most Scrum Teams follow the User Story format for keeping their PBIs focused and effective as invitations to conversations.

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…