Good food for thought there.

This sprint is a little different from many in that most people are local (members of MichiPUG coming to help out, learn and have fun). There are a couple of out of town people, but they’re just driving in for the day.

Still, I do realize that one day is very brief, but then TurboGears is a 3 week old project

As it matures and people use it more, a larger sprint becomes a real possibility.

http://www.infrae.com/about/activities/sprintathon/tips

The PyPy people are good to check out on sprints as well; they have a sprint-driven development model:

http://codespeak.net/pypy/dist/pypy/doc/dev_method.html

Good luck!

– Get a whiteboard which everyone can see (a wiki can work, e.g.
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMF20GoldeggSprint2005

– Especially for such a short sprint, pre-populate the whiteboard with a list of discrete
tasks, ideally ones a pair could knock off in an hour or two. Normally, the first part
of a sprint is taken up with brainstorming / prioritizing these tasks, but a single
day won’t leave enough time to get actual work done as well.

– Encourage people to change partners between tasks: a lot of the value of a sprint
is in the relationships your developer community builds, and mixing up the pairs
helps make a denser mesh.

– Try to ensure that everybody arrives at the sprint with a working development
sandbox already on their laptop, so that even in the networking is manky, people
can still get work done.

– See if you can get the networking set up the day / night before, and test with several
different laptops.

– Arrange for snacks and drinks close at hand, if possible.

– Plan a wrap-up session where people report progress and issues at the end of the
“main” day, and then go out for dinner (extending the coding period late into the
evening can be fun, but is often less productive, and may not fit the circadian
rhythms of all your sprinters.