Bill of Rights

The purpose of the Bill of Rights is to resolve common disputes between customers and developers by defining clear, distinct sets of rights and expectations for effective cooperation. Make sure developers and customers always have this bill available to resolve disputes that arise during discussions. Below is the original version of the Bill of Rights, with the sub-bullets being some of the more detailed explanations.

1. Customer Bill of Rights

You have the right to

• an overall plan and to know what can be accomplished when and at what cost.
  • Developers can't predict the exact amount of work for a story, but they must specify the uncertainties. See here for more details.
• get the most possible value out of every iteration.
  • Developers must work on the features that have the highest level of usable business value. "Usable" means ready to be used effectively by end users, not theoretical business value provided by partial implemented features.
• see progress in a running system, proven to work by passing repeatable tests that you specify.
  • Developers must write acceptance tests that are developed in collaboration with customers.
• change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
  • Software is always expected to be flexible by design, so that functional customization should be affordable. This means that developers are expected to be trained in test-driven development, clean code and architecture to be able to design the software in a way that makes changes affordable.
  • In each iteration, customers have the opportunity to re-prioritize stories and define which stories to implement in the next iteration.
• be informed of schedule and estimate changes, in time to choose how to reduce the scope to meet a required date. You can cancel at any time and be left with a useful working system reflecting investment to date.
  • Customers have the right to be informed in time if there is a delay. They then have the right to decide which stories should be dropped from the project scope, so that at least the most important stories are completed by the deadline. Customers do not have the right to demand that developers implement all originally planned stories and meet specific deadlines if the developers estimate that this is not possible.
  • Because each iteration produces a tested, production-ready and deployable release, customers can technically exit the contract at any time.

2. Developer Bill of Rights

You have the right to

• know what is needed with clear declarations of priority.
  • Developers can ask customers to clarify requirements. Customers have the right to change requirements outside of an iteration, but not within an iteration.
• produce high-quality work at all times.
  • No developer should be forced to damage their reputation or violate their work ethic by delivering low-quality code. It is the developer's right to spend time refactoring code until it is clean.
• ask for and receive help from peers, managers, and customers.
  • With the right to ask for help comes the responsibility to give help.
• make and update your own estimates.
  • Estimates are intelligent guesses, not commitments. Estimates improve over time as new knowledge is gained, so they should be updated.
• accept your responsibilities instead of having them assigned to you.
  • For each iteration, customers specify the tasks to be done, but developers internally negotiate who does what. Developers have a deeper understanding of the technology and team experience, resulting in a more efficient allocation of resources. An individual developer has the right to say "no" to a task during the negotiation process, due to the availability of better alternatives or a lack of confidence in their abilities, and take on another task instead.