Product Backlog Item (PBI) writing in Scrum is best done by pairing a Product Owner with an architect or team member. The Product Owner brings a stakeholder perspective to the table, and PBIs should include that “value perspective” in every case. When the PO is not “primary”, you get PBIs that have no demonstrable stakeholder or business value.
However, some POs think they are the only people who can initially author PBIs. They think they must wait to talk to the whole team to get them into better shape. As a result, the whole team must edit confusing PBIs tied to an uncertain architecture.
When the Product Owner waits for the whole team to meet to incorporate developer insight, Product Planning slows, at very high cost to the organization.
If you find yourself with other team members tediously editing poorly written PBIs in Grooming or Product Planning meetings, suggest a change. Insist that the Product Owner pair with an architecturally savvy member of the team to craft PBIs. Caution the technical member of this pairing team that PBIs must still provide external value. Welcome corrections to the architectural assumptions when the team meets to estimate. Your Planning meetings will likely go faster; the backlog items will likely produce more value.
