'''Customer Bill of Rights'''

'''You have the right to:'''

	0 Declare the business priority of every UserStory
	0 Have an overall plan, to know what can be accomplished, when, and at what cost.
	0 Get the most possible value out of every programming week.
	0 See progress in a running system, proven to work by passing repeatable tests that you specify.
	0 Advise developers of changes in the requirements
	0 Be informed of schedule changes, in time to choose how to reduce scope to restore the original date.
	0 Cancel project at any time and be left with a useful working system reflecting investment to date.

An alternative to
	* Advise developers of changes in the requirements
has been suggested:
	* change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
Note that the first version might more properly be considered a responsibility, while the latter is clearly a right.

From the SoftwareManagementManifesto. See "Manager and Customer Rights" at http://www.xprogramming.com/products.htm.

An Agile project can ...

* implement features in any order
* release any integration
* minimize the average time between specifying and profiting from a feature

So you achieve item 1 when the developers don't mind if you change the priority of userstories in the project backlog.

You achieve item 2, short term, when you and the team learn how to estimate many small bite-sized stories, and you get good long-term estimates by comparing past rates.

You achieve item 3 by actually putting the system into production (or a simulation), early and often. You never need to endure long blackouts.

Programmers deliver 4 by giving you StoryTest''''''s that reflect your own verbiage back as passing tests, using BehaviorDrivenDevelopment. These tests allow developers to release any integration - even one just after you changed your mind!

Because developers write several layers of automated tests, you can generally change requirements early and often. The cost of a given feature does not go way up as the system builds beyond it. So item 5 doesn't mean programmers are not allowed to grumble (or are required to work for free) if you change your mind - or if reality changes it for you. Programmers are expected to create a system that's easy to change.

To get item 6, your developers expect to use DailyDeployment - even if just to a simulation. If they can't, for any reason, their system has spontaneously raised a red flag. The best possible way to respond is renegotiate scope. The developers should _never_ cut quality, just to make a deadline, because the average time for each feature will then inevitably go up.

Item 7 means programmers decrease the odds of a canceled project simply by always striving to behave as if their current week were going to be their last. They always make sure they have created something of value - not just a bunch of build scripts, database tables, diagrams, and disconnected functions - each week. They make sure they only add code that supports live, useful features.

----
You have the responsibility to do your part, and work with others on the WholeTeam, to insure the project's success.
----
See: CustomerBillOfRightsDiscussion, SoftwareManagementManifestoDiscussion, DeveloperBillOfRights, ExtremeProgrammingCorePractices

CategoryCustomer