A key component of ImpactModelling.  These two pages constitute the best introduction until we RefactorMercilessly or delete.

PhilipEskelin summarises the basic idea well when he says towards the end of IsXpSynergistic
	 :	"I think you are right that 100 percent XP pops you into 100 percent value, which to me is defined as being entirely successful at executing the vision of your project."

A single success statement attempts to model just one aspect of what the customer would view as success at some time in the future.  We use Philip's scale, with 100 meaning complete success.  You can use values of less than a hundred for partial success or more for mega-success. (Maybe for PhilipEskelin 200 would stand for being taken out for a celebration meal at Smith and Wollensky's with a price tag of over $500 - see the second section of NonlinearityOfXp.)

A success statement is parameterised (crucially) by the time by which the stated objectives would have to be met to attain the given level of success and the customer/department that would assign this particular success value (so it's all about human perception - woolly but perhaps not that unimportant).

ImpactModelling aims to transform the traditional, bogus FixedRequirementsForWayOffInTheFuture into a dynamic SetOfSuccessStatements relating different possibilities for success over different timescales.  This becomes the foundation for EvolutionaryDelivery of any description, consistent with the SoftwareManagementManifesto.  And certainly, as Philip says, it's the foundation for case by case selection of which subset or superset of XP practices, and indeed which software languages and tools are needed for success.

As with everything else we apply the DocumentToDeliver principle to all this - do only as much impact and other modelling as is needed to deliver the next success.  This is our answer to the BeancountersWetDream objection of JohnFarrell in GilbMeasurabilityPrinciple.

As a project's aims are better and better understood what we are ultimately looking for is a '''Scoop''' (ScribbledOnOnePage):
	* a delivery of very high business value 
	* that emerges suddenly from a well managed, even boring evolutionary process (like a hungry journalist in a well run newspaper recognises a scoop when he sees one)
	* whose success statement and definition can be "scribbled" or alternatively "specified completely" on one page
	* that can be implemented in a day to a week (because the code is well factored, UnitTest''''''ed and so ready for the challenge - see ExtremeNormalForm)
	* using what will seem to users to be S''''''uperChargedObjectOrientedProgramming (the marketing boys were working overtime here but the point is, as TomGilb says, that the end user is only valid judge of productivity.  "How delighted do you want me to be?" as a manager in a major bank in the UK once asked me.)  

The journalistic analogy is deliberate and turns out to be pretty helpful in other ways (except that in the UK the writers are called '''hacks'''!).  It was developed quite independently from that WardCunningham fellow who contributed to DisciplineEnvy a few years back now. 

This is our key motivation for stuff like UnitTest''''''s and RefactorMercilessly during the hard times.

Thanks especially to DannyCoward now of J''''''avaSoft for co-development of the Scoop concept one rainy London day.  It started playing around with the old Java coffee analogies but happily improved from there.

-- RichardDrake
----
Illustrations of what constitute success have been included in a web site called SuccessfulDotCom. A strategy termed 3.5.7 is introduced via a powerpoint presentation. Well worth the visit - http://www.successful.com/australia.ppt 
----
CategorySuccess