Scrum Rules Distilled

As stated in The Scrum Guide, the Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. However, the Scrum rules are not as discernible as the roles, events, and artifacts. This list is an attempt to distill such rules and it is provided as a complementary resource to the Scrum Guide™.

1. The roles, artifacts, events, and rules of Scrum are immutable

Although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and it functions well as a container for other techniques, methodologies, and practices. (pp. 19). The team model in Scrum is designed to optimize flexibility, creativity, and productivity (pp. 6). Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum (pp. 9). Artifacts represent work or value to provide transparency of key information—so that everybody has the same understanding of the artifact—and opportunities for inspection and adaptation. (pp. 14)

2. Significant aspects of the process must be transparent

Scrum relies on transparency (pp. 17), which means that significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects to be defined by a common standard so that observers share a common understanding of what is being seen. For example, a common language referring to the process must be shared by all participants, and those performing the work and those accepting the work must have a common definition of “Done”. (pp. 5) The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. (pp. 17)

3. Scrum Teams must inspect Scrum artifacts and progress frequently

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. (pp. 5, 9)

4. Scrum Teams must adapt processes and artifacts to address deviations

If an inspector determines that one or more aspects of a process deviate outside acceptable limits and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. (pp. 5)

5. The Sprint is Time-boxed to one month or less

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints are limited to one calendar month because when a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of costs. (pp. 9)

6. Sprints Have Consistent Durations

Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. (pp. 9)

7. Sprints are contiguous

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. A new Sprint starts immediately after the conclusion of the previous Sprint. (pp. 9)

8. All the Scrum Events are Time-boxed

All the events are time-boxed, such that every event has a maximum duration. Apart from the Sprint itself, which is the container of all the other events, the events may end whenever the purpose of the event is achieved. The Scrum Master teaches the Scrum Team to keep every event within its corresponding time-box (pp. 10-14).

• Sprint Planning (up to two hours per week of the duration of the Sprint)
• Daily Scrum (15 minutes)
• Sprint Review (up to one hour per week of the duration of the Sprint)
• Sprint Retrospective (up to 45 minutes per week of the duration of the Sprint)

9. The Scrum Master is responsible for promoting and supporting Scrum as defined 

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team (pp. 7). The Scrum Master ensures that all the events take place and that attendants understand their purpose (pp. 9-14).

10. The Scrum Master is a servant-leader for the Scrum Team

The Scrum Masters are a servant first and they focus primarily on the growth and well-being of the Scrum Team and its interactions. The Scrum Master serves the Scrum Team providing guidance, coaching, and facilitating events as requested or needed. The Scrum Master also removes impediments to the Development Team’s progress. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. (pp. 7)

11. The Product Backlog is the single source of requirements

The Product Backlog is an ordered list of everything that is known to be needed in the product and is the single source of requirements for any changes to be made to the product (pp. 15). No one can force the Development Team to work from a different set of requirements (pp. 6). Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”. (pp. 15)

12. One Product; One Product Backlog

Only one Product Backlog is used, even when multiple Scrum Teams work on the same product. A Product Backlog attribute that groups items may then be employed. (pp. 15)

13. A Product Backlog is never complete

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. If a product exists, its Product Backlog also exists. (pp. 15)

14. The Product Owner is the sole person responsible for managing the Product Backlog

The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering (pp. 15). Although the Development Team might perform backlog management activities, the Product Owner remains accountable. (pp. 6)

15. The Product Owner is one person, not a committee

The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner. (pp. 5)

16. The Product Owner is responsible for maximizing value 

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. (pp. 6)

17. The Development Team is responsible for creating the Increment

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (pp. 7)

18. The Development Team is Self-Organizing

Development Teams are structured and empowered by the organization to organize and manage their own work. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. (pp. 7)

19. The Development Team is Cross-functional

The Development Team has all the necessary skills as a team to create a product Increment. (pp. 7)

20. The Development Team has 3 to 9 members

The Development Team size is small enough to remain nimble and large enough to complete significant work within the Sprint. A Development Team with fewer than three members may encounter skill constraints during the Sprint and might be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination and generates too much complexity for an empirical process. (pp. 7)

21. All members of the Development Team share the same title

Scrum recognizes no titles for members of the Development Team other than Developer. (pp. 7)

22. The Development Team has No Sub-teams

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis. (pp. 7)

23. The whole Development Team is accountable

Individual team members may have specialized skills and areas of focus, but accountability belongs to the Development Team. (pp. 7)

24. Scrum Teams must have a shared understanding of “Done”

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. This definition of “Done” ensures transparency and it is used to assess when work on the product Increment is complete. The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. If the definition of “Done” is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If multiple Scrum Teams are working on the system or product release, the Development Teams on all Scrum Teams must mutually define the definition of “Done” (pp. 18)

25. Product Backlog items targeted for upcoming Sprint are sufficiently refined

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” with the Sprint time-box. The Scrum Team decides how and when refinement is done. (pp. 15)

26. The Development Team is responsible for all estimates

The Development Team is responsible for all [size, effort] estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but who will perform the work make the final estimate. As work is performed or completed, the estimated remaining work is updated (pp. 15-16)

27. The Development Team decides how much work to take

The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint. (pp. 9). The Development Team should be able to explain to the Product Owner and the Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. (pp. 10)

28. The Sprint Backlog is the Sprint plan

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog makes visible all the work the Development Team identifies as necessary to meet the Sprint Goal and it has enough detail that changes in progress can be understood in the Daily Scrum. (pp. 16)

29. The Sprint Backlog contains improvement items

To ensure continuous improvement, the Sprint Backlog includes at least one high priority process improvement identified in the previous Retrospective meeting. (pp. 16)

30. The Development Team is solely responsible for the Sprint Backlog

The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team. Only the Development Team can change its Sprint Backlog during a Sprint. (pp. 16)

31. The Sprint Backlog is emergent

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. As new work is required, the Development Team adds it to the Sprint Backlog. (pp. 16)

32. The development Team monitors progress toward the sprint goal

The Development Team tracks the total work remaining in the Sprint at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. The Sprint Backlog has enough detail that changes in progress can be understood in the Daily Scrum. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. (pp. 16)

33. Once a Sprint begins, its duration is fixed

Differently than other Scrum events, which may end whenever the purpose of the event is achieved, once the Sprint begins, its duration is fixed cannot be shortened or lengthened. (pp. 9)

34. Sprints are protected

During the Sprint, no changes are made that would endanger the Sprint Goal and the quality goals do not decrease. The scope may be clarified and re-negotiated between the Product Owner and the Development Team as more is learned. (pp. 9)

35. Only the Product Owner has the authority to cancel the Sprint

A Sprint can be canceled before the Sprint time-box is over, but only the Product Owner has the authority for doing so. Any completed and “Done” Product Backlog items are reviewed, and the Product Owner accepts any part of the work that is potentially releasable. (pp. 10)

36. The Daily Scrum is held at the same time and place

The Daily Scrum is held at the same time and place to reduce complexity. (pp. 12)

37. The Development Team is responsible for conducting the Daily Scrum

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. (pp. 12)

38. Only the Development Team participates in the Daily Scrum

The Scrum Master ensures that only the Development Team members participate (i.e., answer the three questions) in the Daily Scrum. (pp. 12)

39. The Increment is Accumulative

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. (pp. 17)

40. The Increment must be in useable condition

A “Done” increment is required at the Sprint Review. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done”. At the end of the Sprint, the new Increment must be in useable condition regardless of whether the Product Owner decides to release it. (pp. 17)

41. The Sprint Review inspect the Increment and result in a revised Product Backlog

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. The Sprint Review is an informal meeting, not a status meeting. The presentation of the Increment is intended to elicit feedback and foster collaboration. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. (pp. 13)

42. Product Owner monitors progress toward the longer-term goal

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. (pp. 16)

43. The Sprint Retrospective should result in Improvements

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Scrum Master encourages the Scrum Team to improve its development process and practices to make it more effective and enjoyable for the next Sprint. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. (pp. 14)