How Much Should I Prepare for PBR?

If you have attended Product Backlog Refinement meetings, you may understand and appreciate the importance of the conversation that occurs between the experts (sometimes referred to as Subject Matter Experts, or SMEs) and the feature teams.  The insight and understanding gained during that conversation far outweighs any artifacts brought in or derived during a PBR.

You may have seen PBRs that appeared quite chaotic, with “experts” who did not seem comfortable in that role.  Skipping over the discomfort of presenting in public for the moment, sometimes you may be looking at someone who is unprepared to answer the myriad of questions.  The topic may be complex, or the expert hasn’t given it much thought recently.  Therefore, one of the forces at play here is a desire for smooth running PBRs and experts that are fully prepared to have a conversation.

PBR prep sweetspot

This can sometimes go too far, as shown in the image above, where the preparation becomes rigid, perhaps fully documented, and the expert now invested in the artifact to such a degree that they are unwilling to entertain any changes.  The conversation is altered to become the delivery of a fait accompli.  In the worst cases I have seen PBR degenerate into the delivery of a requirements document, with the “expert” withdrawing totally from the conversation.

The answer to the original question of how much preparation is enough is, as always, “it depends”.  You need to understand where your org is on that gradient and be aware not to overshoot the mark in preparation and kill PBR.  Early on I see many more orgs with chaotic PBRs, often due to not inviting the correct experts or not being able to locate experts (now there’s a serious organization impediment that needs addressing!)  For starting out, if writing a requirements document helps structure your thinking so you can fully grasp the requirements, by all means do so.  But don’t confuse that preparation as a substitute for the conversation that PBR brings to the fore.

If you understand all of this, you can probably see why some misunderstand scrum as “not having documentation”, when in fact it’s just the opposite: have just enough documentation.

Leave a Reply

Your email address will not be published. Required fields are marked *