A quick question, probably with a quick answer. I know XP uses CRC on a regular basis, but I'm not certain I understand its relationship to other XP activities. Is it used to go from UserStory(s) to EngineeringTask(s)? From EngineeringTask(s) to IterationPlan(s)? At StandupMeeting(s)? Or for other things? --PeterMerel
----
CRC is more of a tool, than a rule or practice. As such, it's supportive of the above, not a necessary component from, to, or in any of them.

CRC is used any time you need to figure out or communicate how the objects work or should work.  As such, you can use it to generate engineering tasks from user stories, or to work out the details of how some specific engineering task should be carried out.  Can also be used to explain to customer or other interested party how the system works.  With a handful of business cards we could explain to you in a bar how C3 works, for example.

Never used at StandupMeeting, tho a CRC session might be set up at a standup. 

IterationPlan is:

	1. Customers select stories for iteration.
	2. Engineers expand stories to EngineeringTask(s). (might involve CRC, before or after iteration planning meeting.)
	3. Engineers sign up for tasks.
	4. Engineer estimates own tasks in IdealProgrammingTime.
	5. Adjust signup, using LoadFactor, to fit estimates into time available.  (Customer makes priority decisions on what to drop.)

Followup questions?

You say CRC isn't essential, but given XP's emphasis on eschewing intermediary models I don't know of any other design technique that would work - do you? 

And I'm not certain I'm correctly imagining what a C3 EngineeringTask looks like - to what extent it captures carding sessions - could you give an example as you did for IterationPlan?

And ... it seems like you end up with a hellubalot of cards flying round the shop. I can see Tracker drowning in the things - do you junk them all as soon as you can, or else how are they managed?

--PeterMerel
----
See EngineeringTask for examples of generation of same.

CRC isn't an XP "rule" like DoTheSimplestThingThatCouldPossiblyWork.  It is ''the'' design tool, however.  And recall that it is the "simplest" philosophy that leads us to use CRC unless it won't work.  We're toying with whether recording some CRC designs in UML would have utility: to date, we don't see why, but perhaps a need will arise.

Yes, we do wind up with lots of cards.  We gave up using EngineeringTask cards after trying them for a while. We do have a few hundred story cards, however.  Management of these is a bit problematical, with the biggest problem being that we occasionally lose one.  We think next time we'll have a master copy somewhere, which is what was happening by accident at the beginning of C3.  Most of our original cards were made by cutting out sections of documents and pasting them on cards; we may go back to something like that.  

At every point one gets tempted to do something clever, like recording CRC sessions in UML or putting all the cards into a neat book or something.  The trick is to resist these time-consuming activities that don't really serve the project.  (And, as always, if the project really needs some form of documentation, XP would make it a task and do it.  It's the stuff you don't need that we eschew.)  (bless me) --RonJeffries

----
I've read all of the above in detail and still don't get it.  What is CRC?  What does the C, the R, and the C stand for?  Above we see lots of description of context around using it, how, when, where... But we still don't have the "it."  Could someone please explain this to an idiot who has never done "it" and so doesn't know what "it" is?  Thanks.

* CRC stands for Class-Responsibility-Collaboration.  It does not stand for Cyclical Redundancy Checking.
* It involves creating CrcCard''''''s on which one records the responsibilities and collaborators of classes