What Are Sprints?A Detailed Guide
If you’re into work productivity and time management, you’ve likely heard of Sprints. Teams who operate in Sprints seem to get more done and are able to focus better. Plus, Sprints help teams commit to a manageable amount of work, which means you won’t be missing delivery dates that were unrealistic from the beginning.
Sprints originated in software development and are an important part of Agile project management, specifically in the Scrum framework. But what exactly are Sprints?
What is a Sprint?
Sprints are time-boxed work periods where a Scrum team focuses only on the prioritized tasks, and works toward an overarching goal. There are six main phases when working in Sprints, including: Icebox, Backlog refinement, Sprint planning, review, and retrospective.
The purpose of using Sprints is to get everyone on the team aligned on what will be worked for that time period.
This way, new tasks that come up can’t derail progress, and release dates are attainable.
The Sprint process: Step-by-step
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 fulfill 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 can be done in this Sprint?
- How will it get done?
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.
4. Sprint review
Your Sprint is complete. Let’s see how the team did.
The Sprint review is a meeting that’s roughly one hour per week of your Sprints, with a max time limit of four hours per month. The Scrum Master is responsible for sticking to this timebox, and the entire team participates.
The Sprint review is a time to show off what was done and get feedback from the team.
For example, if you released a new feature, a team member might lead a demo during this meeting.
Unlike a Sprint retrospective, the goal of the review is to celebrate work and decide what is “done.” To be considered complete, a task must meet the acceptance criteria that the Product Owner outlined before the start of the Sprint.
Your acceptance criteria should outline the requirements a product needs to satisfy in order to be considered complete. It is not “how” a task should be completed, but the “what” it needs to be complete.
Your Sprint review is also an opportunity to discuss what’s coming up next, based on what was completed in this Sprint.
5. Sprint retrospective
One of Agile’s main principles is continuous improvement, and that's what the Sprint retrospective is for.
Like the name suggests, your retrospective should reflect on the past Sprint, and look ahead to the future.
After the Sprint review, the team will again gather to discuss:
- What should we start doing?
- What should we stop doing?
- What should continue?
Other teams might structure the meeting in terms of “What if?” “I like,” and “I wish.” Feel free to come up with your own list names that better suit your team.
The Scrum Master, Product Owner, and team can all brainstorm ideas or bring recommendations to the table.
Part of this meeting is idea generation, and the other part is prioritizing what from the list to focus on in the next Sprint.
The time limit for this event is 45 minutes per week of your Sprint.
In summary, use this time to investigate how the Sprint went, and make adjustments for better results in the next one.
Plan and execute your Sprints in Hubstaff Tasks
There are plenty of tools for implementing Sprints, one of which is Hubstaff Tasks.
Hubstaff Tasks is an Agile project management tool built with visual simplicity and time-saving features. Focus your team with drag-and-drop Sprints, visualize workflows with Kanban boards, and combine tasks into larger Epics.
The Sprints feature in Hubstaff Tasks clearly displays the most crucial information so that it’s easier for you to conduct Sprint Planning meetings, reviews, and retrospectives while everyone’s looking at the same screen.
At the bottom of your Sprint view is the Backlog, with the option to plan two Sprints into the future. Drag-and-drop tasks to prioritize, and view completed items all in one place.
Also in the Sprint view are your task due dates, estimates, hours worked, and how many days are left in the Sprint. To the left, you’ll see who has that task in their Sprint for a better grasp on asynchronous work. Toggle between your own Sprint, another person’s, and the entire team’s.
You can try Hubstaff Tasks out for yourself — it’s free for 14 days.
Common Sprint pitfalls to avoid
When you’re just getting started with Sprints, it’s normal to wonder what can go wrong.
The nice thing about Scrum is that being able to shift and adjust is built into the framework. If you have the longest Sprint possible at four weeks, that’s only one month of work. And usually you’ll identify issues well before then.
That said, here’s what Courtney Cavey, Scrum certified Product Owner and Director of Marketing at Hubstaff said to watch out for: dependencies and working across teams.
As an example, let’s say your Sprint wraps up at two weeks with items moving to another team in the middle of their three-week Sprint. Your project completion date will have a dependency on that disparity.
Keeping an eye out for what can influence your own team’s Sprint (most often brought up in the Sprint retrospective) can help you avoid this.
Start working in Sprints
Assign work, focus your team, and get more done with easy-to-use Sprints.Try Hubstaff Tasks free