With more and more teams looking to implement Scrum as their practice of choice, we feel there is a growing need to explain its main practices and events. This time, I am covering the topic of what is a Sprint in Scrum and how to implement them within your team.
If you are looking for more information on Scrum in general check out this post:
To begin, let’s first look at the definition of Sprints as it is laid out by Scrum.org. It says:
So, Sprint is a defined period of time during which the Scrum Team performs work required to fulfill the Sprint Goal.
The duration of the Sprint is defined according to the teams’ process and needs, but should not exceed 4 weeks. This is the maximum recommended time for the Sprint duration and while there are exceptions to this rule, most teams do best when staying within this limit.
The Sprint in Scrum contains 4 formal time-boxed events, that all cater to a different Sprint phase:
These events are performed during each Sprint and in the same order. As soon as a team finishes one Sprint, the next Sprint begins.
Need a reminder of Scrum terminology and practices? Grab out the Scrum cheat sheet that lays out all the basics on one page!
As mentioned above, a Sprint in Scrum contains 4 time-boxed events to help the team execute work. The Scrum guide also provides the recommended maximum values for each of these events. Thus, giving you guidance on the most time you should spend in each event.
You should also remember that these values are recommended for a 4-week Sprint. This means if you are running shorter Sprints, they also should be cut down depending on the activity it requires. Planning a Sprint shorter than 4 weeks should take less time, while the Daily standup may remain the same as there is the same amount of team members.
In short, keep these values as a recommendation of the maximum time each event should take. The less time you spend on these events, the more you have to reach the Sprint goal.
And now, let’s look at the 4 key Sprint in Scrum events:
Sprint Planning is the first event of each Sprint. Here the Scrum Team decides what work will be completed during the Sprint and what is the Sprint Goal.
Usually, the Scrum team discusses 3 topics in this event:
This allows the team to lay out their plan in the form of Sprint Backlog and begin working. This is how a Sprint board looks in Teamhood.
Participants – the Scrum Team.
Recommended maximum duration – up to 8 hours.
This is a short daily meeting to inspect what progress has been made towards the Sprint Goal. Each team member shares what they have done and what they are planning to work on next.
If needed, the Developers can adjust the Sprint backlog during this meeting. This is done to accurately reflect the upcoming planned work on the Sprint board.
Participants – Developers.
Recommended maximum duration – up to 15 minutes.
This event is held at the end of each Sprint in Scrum. Its goal is to inspect the outcome of the Sprint with the key stakeholders (clients, partners, etc.). This allows the Scrum Team to check whether their work is what the stakeholders required and adjust the Product Backlog if something needs to be changed.
Participants – the Scrum Team and key stakeholders.
Recommended maximum duration – up to 4 hours.
The fourth and last event in each Sprint is the Retrospective. This meeting is held to review the team’s process and plan ways of increasing quality and effectiveness in the future.
To foster this discussion the Scrum team usually tries to answer 4 key questions:
Some teams use Agile-inspired task boards to write down the answers and then turn them into actionable tasks for the coming Sprint backlog.
Participants – the Scrum Team.
Recommended maximum duration – up to 3 hours.
To begin planning and executing your work in Sprints, first, get familiar with the Scrum terminology and best practices. You can find our library of Agile resources here.
If you are ready to begin, set your events as described above – a 4-week Sprint and the maximum recommended time for each event. As you get more familiar and used to the practice, adjust according to your process and needs.
Also, consider implementing an Agile tool like Teamhood to ease the planning and task management with Agile-centric features.