10.4 Creating & Communicating PBIs
Key Takeaways
- Creating Product Backlog items includes clearly communicating them so Developers understand what is needed and why it matters
- Formats such as user stories are optional techniques—the Scrum Guide does not require a specific Product Backlog item format
- The Product Backlog must be transparent and visible; secret side lists and hidden work break the single source of work
- The Product Owner ensures items are understood, not merely written or ticketed in a tool
- Anyone may propose ideas, but the Product Owner remains accountable for what enters the ordered Product Backlog and how it is communicated
10.4 Creating & Communicating PBIs
Scrum Guide 2020: Creating and clearly communicating Product Backlog items… Ensuring that the Product Backlog is transparent, visible and understood.
A Product Backlog full of cryptic titles is not managed. A beautifully written specification that Developers never discuss is not communicated. This section focuses on how Product Backlog items (PBIs) enter the backlog and become shared understanding—a core Managing Products with Agility skill and a frequent PSPO I discrimination topic (format myths, transparency failures, and “written vs. understood”).
Create and Clearly Communicate (Both Halves Matter)
Effective Product Backlog management includes creating items and clearly communicating them. Creation without communication produces a private inventory. Communication without a real backlog entry produces oral promises that break the single source of work.
| Half of the duty | Failure mode |
|---|---|
| Create | Work exists only in meetings, chats, or executive emails—not on the Product Backlog |
| Clearly communicate | Item exists in the tool but Developers do not understand intent, value, or constraints |
What a PBI needs to convey (conceptually)
Regardless of format, useful communication answers:
- What product improvement or outcome is sought?
- Why it matters (value, user/customer impact, Product Goal link, risk)?
- What constraints apply (compliance, performance bounds, compatibility)?
- How we will recognize progress toward Done for this item (without replacing the Definition of Done)?
PBIs are about improving the product, not about listing every personal task a Developer might do. Tasks and plans for the current Sprint live in the Sprint Backlog’s plan; the Product Backlog holds the ordered opportunities and needs for the product.
Formats Are Techniques—Scrum Does Not Require One
User stories, job stories, use cases, problem statements, spike descriptions, and plain-language outcome statements can all be valid techniques.
| Technique | Typical use | Scrum requirement? |
|---|---|---|
| User story (“As a… I want… so that…”) | Capture user-centered intent | No — optional |
| Job story / JTBD | Context and motivation | Optional |
| Acceptance criteria lists | Shared examples of behavior | Optional practice |
| Spike / research item | Reduce uncertainty | Allowed as product improvement via learning when ordered intentionally |
| Plain description | Clarity without ceremony | Valid if understood |
Exam traps about format
| Trap statement | Better understanding |
|---|---|
| “If it is not a user story, it is not a valid PBI” | Scrum does not mandate user stories |
| “INVEST is required by the Scrum Guide” | INVEST is a helpful quality heuristic for stories, not Guide law |
| “PBIs must use story points” | Sizing method is team-chosen; Developers size |
| “Only features can be PBIs” | Risk reduction, learning, compliance, and quality improvements that improve the product can be PBIs |
| “Epics are forbidden” | Large items may exist lower in the backlog; refine before selection when needed |
Choose answers that reward clarity and understanding, not brand-name templates.
Transparent, Visible Backlog—No Secret Lists
The Product Backlog is the single source of work undertaken by the Scrum Team. Communication includes putting work where it can be inspected.
What transparency and visibility require
| Practice | Transparent? |
|---|---|
| One Product Backlog everyone can inspect | Yes |
| Side spreadsheet of “real priorities” only executives see | No |
| Verbal promises to sales not reflected on the backlog | No |
| Engineering “shadow backlog” of product work outside the Product Backlog | No |
| Tool access exists but permissions hide the real order from the team | No |
| Clear Product Goal visible with the backlog | Yes |
Secret lists destroy ordering accountability. If stakeholders believe a private list is the real order, the Product Owner is not ensuring a transparent backlog—even if the official tool looks tidy.
Visible ≠ understood
Publishing tickets is necessary but not sufficient. The management duty includes ensuring the backlog is understood. That implies conversation, refinement, examples, and feedback loops—not only markdown in a ticket body.
The Product Owner Ensures Understood—Not Just Written
“Clearly communicating” is an outcome: people who must act on the item share meaning.
Signs items are understood
- Developers can explain the value and intended outcome in their own words
- Major uncertainties are named (and spikes ordered if needed)
- Trade-offs are explicit enough to size and slice
- Sprint Planning discussions focus on how to achieve outcomes, not decoding the ticket
- Stakeholders inspecting the backlog are not surprised by what “top” means
Signs items are only written
- Ticket text is copy-pasted legalese nobody discusses
- Different Developers hold conflicting interpretations
- Acceptance debates explode mid-Sprint because intent was never shared
- PO says “it’s in Jira” when asked whether the team understands
| Written only | Communicated |
|---|---|
| Artifact exists | Shared mental model exists |
| PO feels done after typing | PO validates understanding with the people doing the work |
| Ambiguity discovered at the end of the Sprint | Ambiguity reduced before selection when possible |
This is why refinement collaboration matters: communication is often interactive, not monologue documentation.
Who May Create Items vs. Who Is Accountable
In practice, ideas for Product Backlog items can come from many sources:
- Users and customers
- Stakeholders and support teams
- Developers (technical risks, quality improvements, opportunities)
- The Product Owner’s own discovery and strategy work
- Sprint Review insights
Anyone may propose. The Product Owner remains accountable for effective Product Backlog management, including what is on the ordered list and whether items are clear. Delegation is allowed; abandonment of accountability is not.
| Healthy | Unhealthy |
|---|---|
| Developer proposes a risk item; PO orders it after understanding impact | Developer maintains a secret work stream never on the Product Backlog |
| Stakeholder submits requests; PO clarifies and orders | Stakeholder auto-inserts top-of-backlog mandates without PO accountability |
| PO invites users into refinement for clarity | PO never talks to users and only writes from imagination |
Communicating “What” and “Why” to Developers
Developers need more than a feature name. Self-managing teams make better decisions about how when they understand what and why.
| Communicate | Why Developers need it |
|---|---|
| Outcome / problem | Enables thin slices and creative solutions |
| User/customer context | Avoids building for an imaginary persona |
| Product Goal link | Keeps Sprint Goals coherent |
| Constraints | Prevents rework and false Done |
| Non-goals / out of scope | Protects focus |
| Evidence or assumption | Frames learning items and risk |
Do not prescribe every “how” as a PBI requirement
Product Owners who dictate implementation details as if Developers were order-takers undermine self-management—unless a constraint truly is a product requirement (for example, regulatory calculation method). Prefer outcome-oriented PBIs; collaborate on options; let Developers own the plan in the Sprint Backlog.
| Over-prescriptive PBI | Outcome-oriented PBI communication |
|---|---|
| “Add a red button on screen 3 using library X and table Y” as the only acceptance of value | “Borrowers can complete income verification without calling support; prefer mobile web” + constraints |
PBIs, Acceptance Criteria, and Definition of Done
Keep these distinct:
| Concept | Role |
|---|---|
| PBI | What is needed to improve the product (ordered on the Product Backlog) |
| Item-level acceptance ideas / criteria | Optional clarity for that item’s intended behavior or outcomes |
| Definition of Done | Quality standard for any Increment; commitment of the Increment |
Acceptance criteria do not replace Done. An item can meet its acceptance notes and still not be Done if integration, testing, or other DoD elements are missing. Conversely, Done does not mean the PO can skip communicating what valuable outcome the item was for.
Communication Across the Scrum Cadence
| Moment | Communication focus |
|---|---|
| Discovery / refinement | Build shared understanding; split; order; size |
| Sprint Planning | Confirm most important items are understood; craft Sprint Goal; Developers select and plan |
| During the Sprint | Clarify questions quickly; negotiate scope if needed without abandoning Sprint Goal |
| Sprint Review | Inspect outcomes; adapt backlog items and communication of next needs |
| Stakeholder interactions | Gather input; explain order and Goal; no secret second backlog |
Product Owners who only communicate once per quarter in a roadmap slide deck—and never in refinement or Planning—will fail “understood.”
Quality Checklist for Creating & Communicating PBIs
Use this when evaluating scenarios:
- Is the item on the single Product Backlog (not a secret list)?
- Can Developers explain what and why?
- Is format serving clarity, or is the team cargo-culting user-story theater?
- Is the item appropriately detailed for its place in the order?
- If selected soon, can it be Done in one Sprint after refinement?
- Are constraints explicit without micromanaging every implementation step?
- Is the Product Goal still the framing story for why this item exists?
- Did the PO validate understanding—not only hit “Create issue”?
Common Exam Scenarios
| Scenario | Strong response |
|---|---|
| “We must rewrite all PBIs as user stories or they are invalid” | Formats are optional; clarity is required |
| “The PO wrote 200 perfect tickets; Developers refuse because they don’t understand” | Communication failed; refine together; understood > written |
| “Sales has a private priority list for the team” | Merge into one transparent Product Backlog; PO orders |
| “Developers created technical items; PO deleted them because only features allowed” | Product-improving technical/risk/learning items can belong; PO still orders for value |
| “Stakeholder wrote the item, so they own order” | Anyone may create/propose; PO remains accountable for order and management |
| “Item is clear to the PO, so communication is done” | Developers and relevant stakeholders need shared understanding |
Connecting the Four Sections of This Chapter
| Section | Focus |
|---|---|
| 10.1 Fundamentals | Four management duties; delegate work, keep accountability; emergent ordered single source |
| 10.2 Ordering | Sequence for value and other factors; only PO accountable; ordered not fake P1 piles |
| 10.3 Refinement | Ongoing breakdown; ready = Done in one Sprint; Developers size; not a formal event |
| 10.4 Creating & communicating | Clear what/why; optional formats; transparent visible backlog; understood not merely written |
Together these practices are how a Product Owner turns a Product Goal and a stream of ideas into a transparent system of work that a self-managing Scrum Team can pull into valuable Done Increments.
Quick Self-Check
- Create and clearly communicate PBIs—understanding is the goal
- Formats (user stories, etc.) are techniques, not Scrum requirements
- Transparent, visible backlog; no secret lists
- PO ensures understood, not only ticketed
- Many may propose items; PO remains accountable for the ordered Product Backlog
Must Product Backlog items be written as user stories to be valid under the Scrum Guide?
A department keeps a private spreadsheet of “real priorities” while the official Product Backlog shows different items. What is the main problem?
The Product Owner has written detailed ticket text for every top item, but Developers interpret the outcomes differently. What is missing?