Skip to content
    Share this post

    55 Immutable Rules of Scrum from the founding fathers of Scrum.org

    Written by:             Published on: Aug 16, 2018 12:00:00 AM

    Become an in-demand BA in 6 months or less!

    Talk to our Learning Advisor Today

    Slide23

     

    Scrum rules agile world. More than 75% of agile projects follow Scrum.

    However, there are many opinions on what is Scrum and what is not.

    Here is the list of 55 Scrum rules derived from Scrum Guide provided by Jeff Sutherland and Kent Beck, the founding fathers of Scrum.Org.

        1. Significant aspects of the process must be visible to those responsible for the outcome.
        2. Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.
        3. 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.
        4. The required adjustment must be made as soon as possible to minimize further deviation.
        5. Scrum teams value commitment, courage, focus, openness and respect.
        6. Scrum teams are self-organizing, title-free, atomic and cross-functional.
        7. Deliver products iteratively and incrementally, maximizing opportunities for feedback.
        8. Product is the sole person responsible for managing the Product Backlog. (S)he 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.
        9. Product Owner is one person, not a committee.
        10. The entire organization must respect the Product owner’s decisions.
        11. No one can force the Development Team to work from a different set of requirements.
        12. Only members of the Development Team create the Increment.
        13. Optimal Development Team size is between 3 to 9.
        14. All events are time-boxed.
        15. Once a Sprint begins, its duration is fixed.
        16. Sprints have consistent durations throughout a development effort.
        17. A new Sprint starts immediately after the conclusion of the previous Sprint.
        18. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
        19. During the Sprint, no changes are made that would endanger the Sprint Goal.
        20. During the Sprint, Quality goals do not decrease.
        21. During the Sprint, the scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
        22. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
        23. A Sprint can be canceled before the Sprint time-box is over.
        24. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
        25. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
        26. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.
        27. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
        28. Daily Scrum is a 15-minute time-boxed event for the Development Team.
        29. Daily Scrum is held every day of the Sprint.
        30. Daily Scrum is held at the same time and place each day to reduce complexity.
        31. Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
        32. Sprint review is at most a four-hour meeting for one-month Sprints.
        33. Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
        34. Sprint Retrospective is at most a three-hour meeting for one-month Sprints.
        35. Product Backlog is the single source of requirements for any changes to be made to the product.
        36. Product refinement usually consumes no more than 10% of the capacity of the Development Team.
        37. Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
        38. Development Team is responsible for all estimates.
        39. At any point in time, the total work remaining to reach a goal can be summed.
        40. Product Owner tracks total work remaining at least every Sprint Review.
        41. Work remaining information is made transparent to all stakeholders.
        42. To ensure continuous improvement, including at least one high priority process improvement identified in the previous Retrospective meeting.
        43. Only the Development Team can change its Sprint Backlog during a Sprint.
        44. Sprint Backlog belongs solely to the Development Team.
        45. At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.
        46. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.
        47. Increment must be in useable condition regardless of whether the Product Owner decides to release it.
        48. Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent.
        49. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency.
        50. When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.
        51. Scrum Team members must have a shared understanding of what it means for work to be complete, to ensure transparency.
        52. If the definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
        53. If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product.
        54. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done.”
        55. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

        So, These are the 55 immutable Scrum rules Happy implementing.

     

      Previous Next  

    Related Posts

    Write Comment

    Write Comment