What is a Sprint?
In the software development world, especially in the agile software development world, a "sprint" is a fixed, regular timebox that governs your work and how frequently you do updates, demos, or previews.
Usually, a team will decide that they are doing 1-week sprints, or 2-week sprints (or pick your favorite number, but rarely more than about 4 weeks). At the end of a sprint, they will do a demo of what they've accomplished, and if the product owner (a.k.a., the guy in charge of what to build) decides it is good enough for release, it will be released as well. Often, these releases go only to a group of beta testers, rather than all customers, with full releases coming less frequently (3 months or 6 months, or whenever a certain threshold in terms of features completed is met) so that your typical users don't have to deal with updates and changing UI all the time.
In most cases, at the end of a sprint, there will be some sort of demo or review of what was accomplished by the team. These demos are usually fairly simple and informal. They're a chance for people who are following the game or product to get a glimpse into how things are progressing, and offer feedback. They're also a nice way of generating buzz and excitement about what's happening.
It's also pretty typical for people to take a look at what's coming up next, and set goals or plans for the next sprint.
Here's a good example of a game (Space Engineers) that does weekly video updates and weekly software downloads: http://www.spaceengineersgame.com/news.html
Competition #8 Sprint Cycle Guidelines
As a group, we've decided that we're going to follow a sprint cycle during our 100 day competition. Sprints are not required, so don't feel obligated to join them, but I can almost guarantee you will find benefits in doing sprints. Feel free to follow some or all of the guidelines below.
1. We will be doing 1-week sprints. (If you want to run 2-week sprints, all of your sprint boundaries will still line up with everybody else's. That works out pretty nicely.)
2. Sprints will start and stop on Mondays. That means Monday is your day for doing a review or demo of what you've accomplished, and for posting new downloads. If Monday doesn't work for you, feel free to pick another specific day. (But choosing a specific day is a good thing.)
3. The competition starts on Saturday, so the first Saturday and Sunday don't count as an official sprint. We'll call this Sprint 0. Feel free to post an update for Sprint 0 or just roll that into Sprint 1.
4. Your demo/review should be something that is visible to the other people here in the competition. In past competitions, people have made a forum thread specifically for their game, and I would encourage people to keep doing that. The demo or review can come in the form of a text post, a series of screenshots, a shared video on YouTube, a Twitch stream demoing the status, a combination of any of the above, or anything else along those lines that you can dream up.
5. Pay attention to other people's sprint demos, and give them feedback as well. That's what these demos are for.
6. Sharing a compiled build for people to actually play is strongly encouraged, though definitely not required.
7. Sprint planning or settings goals for the upcoming sprint is also encouraged. Telling other people about your goals for the upcoming sprint is a good way to hold yourself accountable.
Other Benefits
Because there's a weekly reset switch, if you got distracted during one week, you can always recommit for the next week.
It also means if you know you're going to be busy one week, you can back off your plans for a sprint, or take it off entirely, and come back fully engaged the sprint after.
There is also the scenario in which you get sick of the game you're working on. Sprint boundaries are great for deciding, "Eh. I'm done with that game, at least for a while. I'm going to work on another game this next sprint." In those cases, it's often better to switch to a game that you'll actually work on than it is to let the one just languish.