One of the things I admired about Extreme Programming (XP) was the simplicity of the roles defined in the Green Book.  In XP, there are only two roles: Customer and Programmer.  When you are using XP, the Customer makes business decisions, Programmers make technical decisions and one role may not substitute their judgement for the other.  In short, Programmers do not make business decisions and Customers do not make technical decisions.  Kent Beck and Martin Fowler even went so far to add a Bill of Rights, which clarifies what people can expect from one another.

Scrum does not have anything similar, so I decided to create my own (modeled on the XP rights).  Feel free to distribute and share.

Every Team member has the following rights:

• To produce quality work at all times.
• To know what is needed from the business with clear declarations of priority.
• To ask for, and receive, help from peers, management, and customers.
• To experiment with new ideas, technologies and roles to grow both as a professional and an individual.

Every Product Owner has the following rights:

• To receive the greatest possible value out of every week.
• To know what can be accomplished by the Team, when and at what cost.
• To see incremental progress in a viable product proven to work by passing acceptance criteria they specify.
• To be informed of schedule changes promptly in order to take effective countermeasures and reset expectations with the stakeholders.
• To collaborate with the business on setting the future direction of the product.

Every ScrumMaster has the following rights:

• To try out different ideas, approaches and techniques to remove impediments which impede the flow of value.
• To be given time for initiatives to take hold and produce change.
• To take measured risks and learn from setbacks.
• To be supported by senior leaders in the organization.
• To be provided access to different parts of the business while identifying and removing impediments.

Every Stakeholder has the following rights:

• To receive regular status updates through interacting with a working product.
• To change their mind, substitute functionality, and adjust priorities without paying exorbitant costs.
• To cancel the product at any time and be left with a working product providing real business value reflecting the investment to date.

This page is also available in: Spanish