Scrum : Quick Reference

Product Backlog :

So what exactly do you put into a Product Backlog

Feature Requests: Any request from a stakeholder (e.g., “I want admin access.” “I want to be able to sort this list.”) 

Nonfunctional Requirements: Qualities of the system (e.g., Performance, Scalable to 2,000 concurrent users, Legal Terms & Conditions) 

Experiments: Functionality that is released to production to test the marketplace (e.g., New UI, User Survey, Analytics); also, experiments can be “enabling constraints,”

User Stories: Placeholders for conversations; popular in the agile community 

Bugs/Defects: Problems that have arisen from a previous release 

Use Cases: List of actions between an actor and a system (not as common these days) 

Capabilities: Different ways or channels to access existing functionality (e.g., mobile, web, cloud services, public API)As a framework, 

Scrum does not prescribe any real method or template for Product Backlog items. However, the vast majority of Scrum Teams populate their Product Backlogs with user stories.

Some example of "Done" List:

•  Unit tested

•  Code reviewed

•  Matches code style guide

•  No known defects

•  Checked into main dev branch 

• Public API documented

• Acceptance tests pass

• Product Owner approved

• Regression tests pass

• Release notes updated 

• Performance tests pass

• User guide updated

• Support guide updated

• Security tests pass

• Compliance documentation updated