The basic time interval for work in a Scrum is called a Sprint. My team uses two-week sprints with formal meetings sprinkled throughout. The formal Scrum meetings simply replace ad-hoc hallway conversations and those demos and design sessions that we "should have had". They key is to increase transparency and avoid ad-hoc interruptions.
Once we have a product backlog defined we have a Sprint Planning meeting where the Product Owner identifies the most important stories to complete in the next two weeks. The developers help by clarifying scope. For example, if the customer wants a huge task done in the very first sprint the developers will flag it. Then the entire Scrum team will break that task into smaller stories and those stories that can be finished in the first sprint get assigned. During the sprint it's great to have the Product Owner come to our daily stand-up meeting to clarify any implementation questions. But if the story is detailed and the task clear the interaction may be minimal.
Scenario: Customer wants full hologram support in first sprint.
Solution: Team will demo basic user interface to launch the hologram.
During the rest of the sprint we have two more regular meetings. The Daily Scrum meeting is early in the morning, and yes, we do it every day. It's no more than 15 minutes long and each developer discusses three things:
What was done yesterday.
What will be done today.
Any issues preventing work from being done.
It guarantees that everyone's on the same page. It's a great place for raising issues and questions that allow people ot pair off after the meeting and resolve. As a note, not every Scrum team in my org have a stand-up every day. Beware of resistance to a daily Scrum, as it might points out a couple of problems.
Symptom 1: We don't have daily stand-up meetings because I'll just say the same thing I did yesterday.
Problem 1: The Sprint is too long, the current Story is too big, or the level of detail given isn't detailed enough.
Symptom 2: We don't have daily stand-up meetings because no one is dependent on another person on the team.
Problem 2: There is too much specialization or not enough backup on the team.
The bottom line here is to avoid meeting every week or two and realizing that days have been lost. The daily Scrum serves as the heartbeat of your project.
The last meeting we have is a Sprint Review meeting on the last day of the sprint. Ideally, all of the work is complete here as well. 
During the review we demo the completed work to the customer, which is usually pretty fun. I haven't experienced any shocked customers (yet) complaining that we've wasted two weeks - it's just too short a duration.
We hold a Sprint Retrospective and review the sprint itself: What went well, what we could have done better, and what we should change. Everyone is asked, the Product Owner, Scrum Master, and Scrum team. This is used to continually improve the scrum process.
Did you really make it this far? Impressive! Look, running a Sprint seems like a lot of work, coordination, and meetings. But it isn't. It's two meetings, one of which just happens every day. Just follow this schedule:
- Once, at the beginning of your project, hold the Product Planning meeting and define a backlog.
- At the beginning of your Sprint and every two weeks after, hold your Sprint Planning meeting.
- Demo the work you've just completed.
- Hold a review of the last Sprint.
- Have the Product Owner define the work from the next Sprint.
- Hold a Daily Scrum every day you don't have a Sprint Planning meeting.
Schedule other team functions, like design meetings, planning workshops, and company-sponsored lunches as needed.
I've been amazed how two recurring meetings have reduced my load as a technical project lead. All of my emergency "how do I?" emails are usually addressed in the Daily Scrum. The customer expectations are set every two weeks. And when we demo, everyone knows where we are and how we got there. So long, Waterfall!
Technorati tags: Scrum Scrum Process