A scrum sprint is a formal iteration in which the team makes an accurate plan in order to increase predictability. They also work on improving productivity by measuring velocity and doing retrospectives.
Scrum is structured around three rituals: sprint planning, a daily standup meeting, and retrospectives.
The team starts with a single backlog, sorted by priority. When team members make an iteration plan, they pull items off the top into a "Sprint backlog" (the current iteration).
Sprint planning often involves the following steps:
Stories are an improvement over just writing down tasks because they provide a better guide to actual user requirements. They also group many implementation tasks into one story, which simplifies the backlog. Sprint teams expand stories into implementation tasks when they pull them into the current sprint.
Managers like the predictability that comes from good sprint planning. Sprint planning can be a great place to get everyone involved in feature design.
However, sprint planning is also a source of problems. Velocity measurement only works when teams are stable, so teams are discouraged from growing their capacity. Planning and estimating takes time from other team activities, and they are hard to perform with large and distributed teams. If you have multiple teams you will want to have "Scrum of Scrum" meetings where team representatives can ask each other about dependencies and tasks they need completed in the current sprint.
Once per day the team gathers for a "Scrum"" or "Standup" meeting. The participants stand, so they will not get too comfortable, and the meeting must be short, so everyone can go back to work. Each person says:
Daily scrum or standup meetings are a good idea for co-located teams. Distributed teams should skip them. Instead, distributed teams should run a continuous chat and post a form online that covers "what I did," "what I will do" and obstacles.
During the implementation of the Sprint, more and more tasks get completed. This can be represented as a "burn up" on our cumulative flow diagram. If everything goes well, the line will be quite straight, and most of the tasks will be complete at the end of the sprint. Remember to release on schedule!
You can map the progress of your sprint on a cardwall where you define the status columns to match your process.
After the iteration is completed, the team does a "retrospective" to discuss what can be improved in the next sprint. It is a good idea to schedule these discussions on a regular basis, and constantly work to improve team productivity and happiness. You can also use a happiness survey.
Scrum is an extremely popular methodology because it tends to raise the level of team motivation, interaction and commitment. The end goal is a "self-managed team."
Scrum enthusiasts encourage teams to stick very closely to the "three rituals," and they disparage any deviation as "scrumbut." However, their recommendations only work well for co-located teams with 5-10 team members, and for major release cycles longer than one month.
If you don't fit that model exactly, you should make some of the adjustments recommended in the following sections of this guide.