A Sprint (also known as an iteration) can be briefly defined as the basic unit of work development in Scrum. This unit has a previously defined time-frame (usually varies from one to four weeks).
The person responsible for defining the duration of a sprint is called Scrum Master (aka the facilitator, the person that mediates the development of the activities between the product owner and the development team).
Normally, a team works towards achieving a consensus about the length of their sprints and, after that, all future sprints will last the same time.
Within the realm of product/software development, a sprint is normally defined as the period of time during which specific tasks (more specifically everything that was listed on the Sprint Backlog) has to be completed and ready for review.
How does a Sprint work?
Each iteration begins with a meeting called “Sprint Planning“. In this event, both the product owner (the person requesting this specific job) and the development team focus towards defining the Sprint Goal and Backlog.
What does that mean? It means that everyone involved in the activities will get together and list all the activities that must be done before this specific iteration can be considered finished. The P.O. and the development team must work to achieve an agreement upon the exact work that must me accomplished during this period of time.
It’s important to remind that, while working with Scrum, a new sprint can only be started once the previous one is done.
This is what makes it extremely important for the team members to make effort and time estimations that are as precise as possible so that everyone will be able to achieve what’s expected of them within the pre-defined timeframe.
For this reason, the development team must always be given the final say when it comes to defining how much work can actually be accomplished during the sprint.
Even though the product owner may have bold goals and final say when it comes to the criteria that determine the approval of the work, the effort, resource and time estimations are the development team’s responsibility.
After the sprint begins, the product owner is expected to step aside and let the development team do their work without hovering or interfering with their jobs. For the duration of the sprint, the team is normally expected to hold short daily meetings to discuss progress and find solutions for eventual challenges.
While the product owner is allowed to attend these daily meetings, he/she is not allowed to actively participate unless he/she is asked a question.
Due to the fact that Scrum works with pre-defined specifications and activities, the product owner is not allowed to request changes during the sprint.
It’s important to stress that, according to the Scrum framework teams are expected to deliver a finished and fully functional product (a new feature for your software, for example) at the end of a Sprint. It’s paramount to keep that in mind when creating time and effort estimates at the sprint planning meeting.
When the development team’s work is finished, they must be able to go through both the Review and Retrospective, when they analyze the overall progress, identify possible improvement opportunities for future sprints and present the achieved results to all stakeholders directly or indirectly related to the elapsed activities.
This is when the product owner will analyze the delivered working according to the criteria he/she established at the planning meeting to determine whether he/she will accept or reject the delivery.