Too long, didn’t read?

The Scrum Guide is short, concise and informative. I encourge you to read it. But if it’s too long to you, or you need to onboard a busy team, follow me on my new blog series 2-Minute Scrum for Busy Teams — a bite-size, per-chapter, bullet-point summary of The Scrum Guide.

Product Backlog

Product Backlog is:

  • the single source of all change requests to the product (features, functions, requirements, enhancements, and fixes)
  • an ordered list of Product Backlog items
  • a living artifact

Product Backlog is never complete:

  • started with initial known and best-understood requirements
  • evolves as the product and its market evolves
  • constantly changes to identify what the product needs to be appropriate, competitive, and useful

Each Product Backlog item:

  • has these attributes:
    1. description
    2. order
    3. estimate
    4. and value
  • and often include:
    • test descriptions that prove its completeness when “Done”
    • an attribute to group items

When multiple Scrum Teams work together on the same product:

  • one Product Backlog is used

Product Owner:

  • is responsible for Product Backlog content, its availability, and ordering

Product Backlog Refinement

  • an ongoing process of adding detail, estimates and order to Product Backlog items
  • consumes max 10% capacity of Development Team
  • higher ordered items:
    • are clearer and more detailed
    • has more precise estimates based on greater clarity and increased detail
  • lower ordered items:
    • has less detail

Scrum Team:

  • decides how and when refinement is done

Product Owner and Development Team:

  • collaborate on reviewing and revising the details of Product Backlog items, so that they:
    • can reasonably be “Done” within a Sprint
    • are deemed “Ready” for selection in Sprint Planning

Product Owner:

  • can update Product Backlog items at any time

Development Team:

  • is responsible for all estimates
  • Product Owner may influence by helping it understand and select trade-offs
  • but people who will perform the work make the final estimate

Monitoring Progress Toward Goals

Product Owner:

  • tracks the total work remaining every Sprint Review
  • assess progress toward completing the projected work
  • makes this information transparent to all stakeholders

Useful projective practices to forecast progress:

  • burn-downs
  • burn-ups
  • or cumulative flows

But these do not replace the importance of empiricism:

  • in complex environments, what will happen is unknown
  • only use what has already happened for forward-looking decision-making


Read the full text in The Scrum Guide.

In 2-Minute Scrum for Busy Teams series