What should programmers be doing when they're done implementing all the engineering tasks they signed up for, refactoring or more thorough unit testing?

Related Wiki Pages:

Egroups:
	"What happens at the end of an iteration?" (http://groups.yahoo.com/group/extremeprogramming/message/15818)
	"Trivial question about iteration planning" (http://groups.yahoo.com/group/extremeprogramming/message/16404)
	"What would you do?" (http://groups.yahoo.com/group/extremeprogramming/message/18187)

	(Digest 580/7, 580/10, 581/22, 619/9, 697/5, 700/1)

For more XP implementation issues, see ExtremeProgrammingImplementationIssues
----

Hmmm...write their own Wiki?  Go and shoot some hoops?  There are lots of things to do when work isn't calling.

'''Ask the customer for more work to do, so as to deliver more value sooner?'''
----
Assuming that the people with slack are not always the same ones (indicating some inaccuracy in estimations), why not let them enjoy the slack time with things '''they''' choose to do?  The FortyHourWeek is a tenet of XP, but I suspect that there is no magic in that number 40. --PeteHardie
----
Regardless of how bugfree the system is, any software in active use is accumulating a list of small, shall we say, 'features,' where there are small discrepancies between how the users want the system to behave and how it actually works. Call them anomalies, rather than bugs. :) The development team should be tracking these, and prioritising them, and fixing them as they are working in the relevant code to implement new stories. But there always seems to be a nagging set of little issues that don't get resolved in this way. This "anomaly sludge" is great fodder for spare time. -- BillBarnett

----
Pan for gold and try not to lose your shirt in the process.  My home projects never seem to want to be delivered?  Curious thing..--Aaron Sevivas