What is a Scrum Sprint?
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 that are linked to each other, in a linear way. At the end of each sprint the product increment grows larger. Each sprint is built on top of the outcome from the previous sprint.
Sprint duration is fixed. The length can be between 1 to 4 weeks, and is decided by the Scrum Team from the beginning. The objective 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 whole duration of the process. In the beginning of the project, the product increment will be very simple with very basic functionality, but each sprint iteration incrementally builds on the functionality already completed in the last product increment, which is why Scrum is described as 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, which the customer considers the highest value.
Which is the process of a Sprint?
Each sprint begins with a sprint planning meeting, where items are moved from the product backlog to the sprint backlog, signalling 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 authority to say what is in the sprint. The Scrum team says how the work will be completed, breaking each item into small tasks with a time estimate.
The time estimates are used to determine when the work added to the sprint backlog meets the capacity of the team during the next sprint (also called the velocity). At this point, 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.
Daily Scrum meetings are held 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 is responsible for removing impediments so the team can continue to make progress. When the duration determined for the sprint is over, the sprint concludes with the sprint review meeting. In this meeting, the team demonstrates 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 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 use to working as a team. That is why the 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 were encountered. The team can then focus on the root cause of the issues and put processes in place, to ensure the same issues are not encountered 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 is allowed to focus on how that work is accomplished during the sprint. This enables the team to become self-organising 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.
What a SCRUM Master is doing?
Until this point is reached, the SM must protect the sprint, it must ensure the team does not exceed its capacity, when taking on work in the sprint planning meeting. Exceeding its capacity means the work will not be completed in the sprint. The associated user story will not be accepted as done, and the feature will not be demonstrated 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 functionality that can be accepted from the product backlog in that sprint. The Scrum Master must also ensure the Scrum values are followed 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 a organising Scrum team. This group includes executives, customers, managers, and others with a vested interest in the project. External stakeholders normally contribute 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 success of the project, they are not committed to completing the work of the sprint like the Scrum team. Also, external stakeholders are not involved in the sprint planning meeting, or the day-to-day development. Which means their knowledge is incomplete on many facets, such as the task breakdown, how the task 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 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:
- stakeholders can observe the Daily Scrum stand-up meetings, but they cannot intervene. The Daily Scrum is a time-boxed meeting, if a stakeholder is talking and asking questions, the team is not communicating their status and the goal of the Scrum meeting is not met.
- once the team commits to the items in the sprint backlog, no other items may be added to the sprint. If new requirements are added once the sprint starts, the team will most likely be over capacity and not be able to complete the work in the sprint. Also the team will have limited time to breakdown the item into tasks and plan for it, if it is not accepted in the sprint planning meeting.
- the team has complete authority over how the user stories are to be completed within a spring. The Scrum master must ensure no outside influence has the authority to oversee, or change the technical decisions of the team.
- the Scrum artefacts provide transparency to the team's progress, and the Scrum meetings are well defined, providing means for all Scrum members and external stakeholders to influence the project at the appropriate time.
Some (final) thoughts
The team should not be required to attend additional status meetings, or give additional status reports, as this indicates an outside authority is operating to influence the team, undermining its effort to be self-organising and autonomous.