In VisualizingRisk a contributor wrote the following, originally from (and might still be in) ThreeWeekProjectTurnaround. I've summarised it to point form here - I think it's easier to follow. Thoughts and suggested changes welcome.

For a project:

'''Define the work'''

* Get a large bulletin board
* Get a bunch of index cards.
* Write the user stories from the requirements group on the cards.
** If a UserStory is too big to fit on a card, get the user to agree with you about how to break it into multiple stories.
** If some small and closely related stories can reasonably be combined, do so.
* Put all the cards up on the bulletin board.
* Give the technical leads a half hour to review the cards and suggest any further splits or combinations needed so each card represents a single, cohesive user story.
* Get the users to agree to the cards or explain any revisions they need to these requirements.

'''Take a break.'''
----
'''Prioritise the work'''

* Have the users prioritize the cards. 
* Reorder the cards with top priority items at the top.
* Have the technical leads review the first priority group to give their opinion about whether all these items can be included in your three weeks.
** If so, decide which second to ''n''th priority items will be scheduled for the release three weeks from now.
** If not, have the users decide which of the first priority items are most useful to them to have first.

* If you have more cards than can be completed in the release for three weeks from now, have a scribe collect the cards, transcribe them, and put them on the project web site as "wish list for future versions, not scheduled yet".

* You're done with the users for the morning.
----
'''Assess the risk'''

* Have the technical leads bring in their developers.
* Move all the cards to one side of the board, representing "high risk". 
* Any developer who is confident that they can readily complete the software to fulfill the story, without having to learn anything new or to break a sweat, can move the card almost all the way to the other, "low risk" end of the board. 
** The far end of the board, "zero risk", is empty so far.
*** Zero risk of development failure means
**** you've completed the software that passes the UnitTest''''''s,
**** the user agrees that the software meets the requirement.
** Eventually all the cards for this release will be moved to "zero risk"
* Any developer who thinks they can probably learn what is needed and do the job without too much trouble can move a card to the "medium risk" section.

----
'''Assign the work'''

* Assign pairs of developers to conduct SpikeTest''''''s on the high risk cards.
** Start by asking for volunteers.
* Any remaining developers are assigned to examine the "medium risk" items and to report back tomorrow on what would have to be done to move these to the "low risk" category.

* Developers should spend some of their time writing UnitTest''''''s that could only be passed by software that meets the requirements, and check the tests into the source control system.

* Throughout the remainder of the project, as programmers complete work that lowers the risk of any particular card, move the card over as appropriate.
* Before moving a card, the development pair must check in code, documentation, and completed unit test results to the project web site.

'''Do the work'''

Developers will have the following priorities for the following three weeks:
	1 Complete their current SpikeTest, moving a high risk item to medium or low risk;
		* OR realize that they're in over their heads on it, and request help.
	1 Help others with their spike tests on request, or take over spike tests they could more readily complete.
	1 Complete discovery of factors that reduce medium risk to low.
	1 Research factors that would reduce medium risk to low.
	1 Complete the UnitTest''''''s for low risk code.
	1 Complete low risk code that passes the corresponding UnitTest.
	1 Check in and document low risk code which now is no-risk code.
		* Look for the highest priority remaining item available on which the developer feels competent to contribute.
		* If not all projects are adopted by volunteers, then starting with the highest risk projects, technical leads will use a random process to select among the most likely qualified developers.

----

An OldMaster once said "never trust a visualization book that lacks pictures".