The simple definition is a short time-boxed period for the scrum team to finish the work based on a specific goal.
The Agile software development and SCRUM practice is a series of sprints linked to to each other, linearly. At the end of each sprint the product increment grows larger. We build each sprint on top of the outcome from the previous sprint.
The length of the sprint can be between 1 and 4 weeks, and the scrum team decides from the beginning. The aim is to have a sprint long enough to include complete user stories in it, but also short enough to be easily manageable.
The duration remains the same for the entire duration of the process. In the beginning of the project, the product increment will be very simple with very basic functionalities.
Each sprint iteration incrementally builds on the functionality already completed in the last product increment, and therefore Scrum framework is both iterative and incremental.
And since each sprint includes the highest priority items in the product backlog, the resulting product increment will always include the features, considered having the highest values by the customer.
Each sprint begins with a sprint planning meeting, where items are moved from the product backlog to the sprint backlog, signalling that they will be completed in the upcoming sprint. The product owner maintains the product backlog with the highest priority items at the top.
So, the product owner has the authority to say what is in the sprint. The Scrum team decides how the work will be completed, breaking each item into minor tasks with a time estimate.
The time estimates are used to determine when the work added to the scrum sprint backlog meets the capacity of the team during the next sprint (also called the velocity). The team commits to completing the work in the sprint backlog, which is frozen; no more items can be added to the sprint. During the sprint, the team owns the work and retains absolute responsibility for completing it in the manner that best suits the team.
We hold Daily Scrum meetings with the team and the Scrum master, to check-in and communicate where each team member is on the task they have accepted.
During the Scrum meeting, each team member reports what they did yesterday, what they will do today and any impediments blocking them. The Scrum Master removes impediments so the team can continue to make progress. When the duration determined for the sprint is over, the sprint concludes with the scrum sprint review meeting. In this meeting, the team shows the functionality added to the product increment, to the product owner.
Customers and stakeholders often attend the sprint reviews, to monitor the product increment as it grows and develops over multiple scrum sprints. The sprint review also provides the opportunity for the stakeholders and customers to give feedback to the product owner and team after they see the product increment demonstration.
The performance of the team during the sprint will vary, especially at the beginning of the project when the members are not yet used to working as a team. That is why the scrum sprint retrospective meeting is held after every sprint, so the team can openly discuss the events of the last sprint, what worked, and what issues they encountered.
The team can then focus on the root cause of the issues and put processes in place, to ensure they do not encounter the same issues in the next sprint, leading to continuous process improvement.
It is essential for the Scrum process that the Scrum team has authority over the work they take on and may focus on how that work is accomplished during the sprint. This enables the team to become self-organizing with no set leader. Over time, the team will establish a consistent velocity for the amount of work they can complete in a sprint.
This helps the team accurately estimate how much work to take on in each sprint planning meeting. As the team gets better at working together, its velocity will increase and more work will be accepted and completed in each sprint.
Until they reach this point, the SM must protect the sprint, he must ensure the team does not exceed its capacity when taking on work in the sprint planning meeting. Exceeding its capacity means they will not complete the work in the sprint. The associated user story will not be accepted as done, and they will not demonstrate the feature in the product increment in this sprint review.
The work not completed is technical debt, which will need to be worked in a future sprint, reducing the new functionalities that can be accepted from the product backlog in that sprint. The Scrum Master must also ensure they follow the Scrum values within the team. Especially important are the Scrum values of staying focused on the work in the sprint, and respect for everyone involved in the project, especially other team members.
The SM must also protect the team from outside influences. External stakeholders are the biggest threat to an organising Scrum team. This group includes executives, customers, managers, and others with a vested interest in the project. External stakeholders normally contribute with resources to the project, or they are responsible for aspects of the projects such as budgets, schedules, or priorities.
Because of that, they often feel they have a right to step in and micro-manage a sprint or overturn a team's decision. While stakeholders have a legitimate stake in the project's success, it does not commit them to completing the work of the sprint like the Scrum team. Also, external stakeholders are not involved in the scum sprint planning meeting or day-to-day development. This means their knowledge is incomplete on many facets, such as the task breakdown, how the tasks are being worked, or why the team estimated a user story as a large or small relative level of effort.
The SM must protect the scrum Sprint, by ensuring external stakeholders do not overly participate in the day-to-day activities of the team which has a detrimental effect on the team's focus and can derail the entire Scrum effort. The Scrum Master can do this by enforcing Scrum rules:
We should not require the team to attend additional status meetings, or give additional status reports, as this shows an outside authority is operating to influence the team, undermining its effort to be self-organizing and autonomous.
This article is part of a bigger topic called: Agile Software Development
Some (final) thoughts