Scrum ceremonies (also known as events) are time-boxed, which makes them easier to adhere to while also having flexibility within that time frame. There’s a limit to how much time you can spend on something, but not a minimum. As soon as the objective has been reached, you’re encouraged to end the meeting sooner.
Since Agile teams exist in different businesses and fulfil different roles, the specifics of each step might vary. Development teams might approach the Sprint review differently than marketers, for example.
However, there are some Scrum guidelines that will make implementing Sprints easier. Here are the steps of the Sprint process you should know.
Before you get to Sprints, you’ll fill an Icebox. The Icebox is essentially a freeform idea list where anyone can add thoughts and potential tasks.
Similar to the Backlog, which we’ll discuss next, the Product Owner (PO) owns the Icebox, and can move tasks around in priority before the Sprint planning call. Stakeholders can contribute to the Icebox, as well.
Tasks that are going to get worked on move into the Backlog, where the team will discuss and refine before the Sprint starts.
Another way to look at it is like this:
Sprints: What you’re working on now
Backlog: What you’ll work on next
Icebox: What you might work on at some point
2. Backlog refinement
The Backlog is where all of the team’s tasks wait to be assigned to a Sprint.
Backlog tasks originate in the roadmap, which means that each item listed should help accomplish the overarching objective. Backlog items may change or shift based on customer input or changing requirements as the project progresses.
The Product Owner oversees the Backlog, and regularly reviews and prioritizes it, which is known as Backlog refinement (Backlog grooming).
How to handle Backlog refinement
The Product Owner is responsible for outlining the details for the highest priority Backlog items.
As the project moves forward, new customer input or revised estimates can influence Backlog tasks. The PO then will go in, make sure the most important tasks are at the top of the list, and that they’re ready for the next Sprint planning meeting.
The items at the top of the Backlog should have the most detail, and should be ready to be moved into the Sprint. These tasks each get velocity points, which can be described as your team’s capacity for work during a Sprint.
Tasks at the bottom of the list are more vague and need more input before they’re ready to be worked on.
The Backlog is not:
An idea dumping ground
An unorganized list of tasks
Set in stone from the beginning of a project
Ignored until right before Sprint planning
A formal, scheduled event
3. Sprint planning
Sprint planning is considered the kickoff for a Sprint.
The event itself shouldn’t be more than two hours for each week of your Sprint, with one hour per week set as the average. The maximum duration is 8 hours (never more), and shorter for Sprints under one month. There is no minimum duration.
Sprint planning helps teams determine two things:
What happens in Sprint planning and who is involved?
The entire Scrum team participates here: the Scrum Master, Product Owner, and the rest of the team. The Product Owner leads the meeting by outlining the goal for that Sprint, and which backlog items might help accomplish it. Then the team jumps in and decides what can be accomplished in that timeframe.
Together, your team takes items from the Backlog and moves them into the Sprint. Not only do you discuss what will be focused on, but you also get into the details of how the work will get accomplished.
This stage of planning is crucial because the goal of a Sprint is to focus only on the tasks you’ve decided to tackle as a team.