What is a sprint?
Sprints set the rhythm of scrum. A sprint is a fixed-length iteration during which the scrum team completes a set amount of work. Sprints encourage predictability and rapid learning. Immediately after one ends, a new sprint begins. And the cycle continues — a consistent drumbeat of development.
Are sprints part of agile or scrum?
Scrum is one of the most popular agile software development methodologies. It offers a defined process framework for planning and delivering usable software. But ubiquity brings dilution.
Many engineering teams who do not follow the full scrum framework will break development work into increments they call sprints. Are they agile? Or some sort of scrum hybrid? And does it really matter?
To answer that last question: yes and no. If you are a scrum devotee? The rules matter. Terminology is part of adherence to a particular framework. In large organizations in particular, consistent planning processes are essential for coordinated delivery across many development teams. But what matters most is that you are delivering business and customer value at a consistent pace, incorporating user feedback and collective learning as you go. The wrapper is not as important as what is inside.
Scrum is popular for a reason. For many organizations, it works. So sprint forward toward your goals — in the way that best suits your team.
What is a sprint in scrum?
Everything happens during a sprint. You can think of a sprint as a discrete project within the broader effort of developing a product. All of the scrum events — planning, daily scrums, review, and retrospectives — occur during the time frame set by the scrum team.
What are the rules of a sprint?
There are specific rules within a sprint, as defined in the scrum guide (which is updated annually). A sprint may be cancelled if the product goal becomes obsolete — but only the product owner has the authority to do so.
Current rules related to an in-progress sprint include:
No changes can be made that would endanger the sprint goal
Quality does not decrease
The product backlog is refined as needed
Scope may be clarified and renegotiated with the product owners as more is learned
How long is a sprint?
The aim of a sprint is to make progress against the product goal. So the scrum team determines and agrees to a consistent duration for completing work. Most sprints range from two to four weeks — but should not be longer than one month. If the time box bloats past a month or so, you can end up with too much complexity and associated risk. Work becomes unwieldy. And the scrum team loses out on the opportunity to review and adapt. Rapid iteration with built-in learning cycles is the benefit of compressed sprint time frames.
What is sprint planning?
Sprint planning is collaborative. The intent is quite simple. You want to choose what will be prioritized and how that work will be done. During a sprint planning session the product owner, scrum master, and development team work through the following questions together:
Why is this sprint important?
What can be done during this sprint?
How will the chosen work get done?
The product owner shares the goal that needs to be achieved during the sprint and selects items from the product backlog that support the goal. Features chosen must align with the overall product vision and product roadmap. The sprint goal should be clearly understood by everyone on the scrum team, so that success can be objectively measured.
Once the product backlog items are selected, the team creates a plan for how that work will be done. This “plan” is called the sprint backlog. It is prioritized and then managed by the team as items move through the workflow.
According to the scrum framework, a planning event should reflect the duration of the sprint. There is a limit of eight hours in total for a four-week sprint. Shorter sprints will have shorter planning events.
What is a sprint review?
The sprint review is the penultimate event before the sprint concludes. Like most events in scrum, there are limits on how much time a sprint review should take — no more than four hours for a four-week sprint.
The purpose of the sprint review is for the scrum team and stakeholders (invited by the product owner) to review what was planned and what was accomplished. Progress against the product goal is discussed. The development team shows the work that they have done and answers questions. The product owner shares the current product backlog. Then together, based on the results, the entire group will discuss what to do next.
What is a sprint retrospective?
Adaptability and rapid learning are hallmarks of scrum. The sprint retrospective is an opportunity for the team to introspect and evaluate how to improve. This event occurs immediately after the sprint review.
Everyone on the scrum team should participate in the retrospective — the product owner, the scrum master, and the developers. Sprint retrospectives are typically an hour or less. But if a sprint was riddled with complications or hurdles, the team could spend longer debating the best way to avoid in the future.
During a sprint retrospective, the scrum team should evaluate the past sprint and decide what to start doing, keep doing, or stop doing. These choices should not be based on emotion or opinion. Instead, outcomes of a sprint retrospective should be based on fact, experience, or some other empirical evidence.
Related guide: Sprint retrospective templates
What tools do scrum teams use to manage sprints?
Scrum ensures transparency, collaboration, and flexibility. Most scrum teams use purpose-built software to store product and sprint backlogs, as well as to manage the in-progress work. If you are evaluating tools for your scrum team, look for agile software development products that offer the ability to:
Organize backlogs
Define user stories
Prioritize features
Develop sprint goals
Coordinate sprints
Manage work on a scrum board
Collaborate during daily scrums
Document reviews and retrospectives
A great scrum team needs the right agile development tools. Try Aha! Develop free for 30 days.
