Introduction
A sprint is a short, time-boxed period allocated for a team to complete a set amount of task work. Sprints are usually 1 or 2 weeks long, but can be as short as 1 day or as long as 4 weeks. The purpose of a sprint is to define specific goals that the team will work towards and complete during the sprint period. A project may require one or more sprints in succession, depending on the size and complexity of the project.
The sprint itself is a cycle that a team follows to help coordinate and manage their work. The cycle begins with a sprint planning meeting, where the team gets together to decide what they will work on during the sprint. The team then works on the tasks they have chosen to complete, and at the end of the sprint, they hold a sprint review meeting to discuss what they have accomplished. Finally, the team holds a sprint retrospective meeting to discuss what went well and what could be improved for the next sprint.
This structure allows for quick course corrections based on a tight feedback loop. If something didn’t work out in the last sprint, the team can adjust to avoid this approach in the next one.
Sprint Planning
Unlike project planning, where we split a big task up into many smaller tasks, sprint planning is the process of selecting these tasks from the backlog and including them in a weekly target. The backlog contains all tasks that have neither been planned into a sprint, nor completed. With each sprint cycle the backlog should become smaller as tasks are completed.
Sprint planning should be done as a team, with all members present, as early in the sprint as possible. The first task in this meeting is to agree on priorities. The team should decide which tasks are most important to complete in the next sprint. This is a good time to discuss any new tasks that have been added to the backlog, and to remove any tasks that are no longer relevant. The aim of this process is to establish a clear order for each of the tasks entering the sprint plan.
Once these are agreed, we can begin to allocate tasks to team members. This should be done in a way that ensures each team member has a similar amount of work to do. It is also important to consider the skills and experience of each team member, and to allocate tasks accordingly. For example, if a task requires a specific skill that only one team member has, it would make sense to allocate that task to them. If tasks have been estimated, we may use story points to help allocate tasks fairly.
Sprint Execution
Following the sprint planning session, each developer should have a clear idea of which tasks they are responsible for completing this week, and in which order these should be completed. The team should also have a clear idea of which tasks are being worked on, and which tasks are still in the backlog.
Daily Scrum
It is common to hold a daily scrum or stand-up session to discuss progress on the sprint. This meeting should be short, and should involve all team members. Each team member should answer the following questions:
- What did I do yesterday?
- What will I do today?
- What obstacles are impeding my progress?
This session may be a video call, in person or done asynchronously via a chat channel. The aim of this session is to keep the team up to date with each other’s progress, and to identify any issues that may be slowing down the team.
Task Work
Following a scrum session, a developer is free to begin their allocated task work. This may involve creating new branches, installing new packages, writing new code, or any other development task that is required to complete the task. If we experience issues, these should be recorded in the task itself, so that the scrum master can help to resolve them.
Each task has a status field which is used to keep track of the progress of the task. This field should be updated regularly to reflect the current state of the task. Some common status fields are:
new- The task has been created, but not estimated.backlog- The task has been estimated, but not planned into a sprint.todo- The task has been planned into a sprint, but not started.in-progress- The task has been started, but not completed.in-review- The task has been completed, and is awaiting review.done- The task has been completed and reviewed.blocked- The task is blocked by an external issue.
Ideally, task progress should follow a smooth journey from new to done. However, it is common for tasks to become blocked by external issues. If this happens, the task should be updated to blocked, and the issue should be recorded in the task itself. The scrum master should then work to resolve the issue, and update the task status accordingly. For example, a small task to update a link on one page might become blocked by a lack of information on the link address. In this case, the task is blocked, the Scrum Master should contact the client to request the information, and update the task status to in-progress once the information has been received and the task can be continued.
Once a developer’s tasks are complete, they should be reviewed by another developer. This review process is important to ensure that the code is of a high quality, and that it meets the requirements of the task. If the code is not of a high quality, or if it does not meet the requirements of the task, the reviewer should leave comments on the task, and the developer should make the necessary changes. Once the code has been reviewed and approved, the task status should be updated to done.
When a developer has finished all of their tasks for the sprint, they should inform the scrum master. The developer may be rewarded with time off, or reassigned to another task depending on the needs of the project.
Sprint Review
At the end of the sprint, the team should hold a sprint review meeting. This meeting is used to demonstrate completed tasks, and to discuss any delays that arose during the sprint. The team will examine the backlog, their velocity and the remaining work that lies ahead. A review session may involve the client or product owner if they are available. The aim of this session is to update the awareness of project progress and the current status of the product.
Sprint Retrospective
While the review is focused on the product itself, the retrospective is focused on the process. The team should discuss what went well during the sprint, and what could be improved for the next sprint. This is a good time to discuss any issues that arose during the sprint, and to identify ways to avoid these issues in the future. The team should also discuss any new tasks that have been added to the backlog, and to remove any tasks that are no longer relevant. The aim of this process is to establish a clear order for each of the tasks entering the sprint plan.
For example, if a team are allocating too much work per developer, a retrospective would be a good time to discuss changing the pace of work. Or, if a team is experiencing issues with a particular technology, a retrospective would be a good time to discuss alternatives. The aim of this process is to identify ways to improve the process for the next sprint.
Conclusion
After review and retrospective, the cycle is completed and the next sprint may begin. In the event that this is the last sprint in a project, the review or retrospective sessions may be complemented by a ceremony to celebrate the completion of the project. This is the developer’s chance to show off their work, and to celebrate their achievements.