- Whilst the athletic related names may seem to not make sense at first, the idea of working in sprints is to make a big task much more manageable. Instead of thinking of a project as a big marathon, if you place project creation into smaller manageable sprints, the project becomes much more doable. Lets find out more about the sprint.

Past the athletics analogy, its essential to think of the sprint as the heart of the scrum. It is set in a time-box of up to 1 month but some scrum teams work in smaller sprints. The team that created this learning course that you're viewing works in 2 week sprints for example.

The purpose of the sprint is to release a usable and potentially a releasable product, it's not about releasing the whole product, just a usable one. The product released is an increment, the work that goes into creating that increment happens in The Sprint. They have a consistent duration throughout development, that means the scrum team will always have the same length script. This can however be changed if the scrum team decides that a sprint is too long or too short for example. When a sprint ends a new sprint immediately begins.

As mentioned, the majority of the sprint is made up of a development team working during the sprint to release the product increment. However the other scrum events occur within a sprint. We'll cover each of these in more depth in later videos, but here's an overview.

The first event is the sprint planning where everything that's going to be worked on is decided. The second are the daily scrums, where the team updates the rest of the team on their progress, well, daily. Third, is the sprint review where the product increments created are reviewed by the team, the product owner and the stakeholders. Finally is the sprint retrospective or retro; this is where the development team reflects on the previous sprint and the team then makes adjustments for future sprints. Each sprint has a goal, this is normally to produce a product increment.

As mentioned the core purpose of the sprint is to produce a product increment. The team works towards meeting the sprint goal set during the sprint planning meeting, which is normally to produce a particular increment. Changes can't be made that may put the sprint goal in danger. Any quality goals don't get decreased. The scope of the sprint, that is, all of the work that makes up the sprint aiming to meet the sprint goal, can be renegotiated with the product owner. This is mostly the case if the dev team find out more about a particular task, and that means it may take more or less work to get a task done.

If you have a sprint that's longer than a month you can often lose sight of what's supposed to get done. Any task that's too long often faces procrastination or loss of motivation, and setting a goal that's too far away can often create that sort of environment. The sprint can essentially be considered a project with up to a one month window. And remember, the purpose of the sprint is to get stuff done, don't get bogged down in processes.