What is a sprint for agile and scrum teams?

Have you ever participated in a 100-, 200-, or 400-meter sprint? If so, think about what that sprint was like. A quick Google search on sprinting in sports reveals the following characteristics:

• Short distance
• Consistent speed throughout the distance
• Time-boxed (completed within a specific time limit)
• Energy fully expended by the end

In essence, a sprint is a short distance run at a high, constant speed, with the athlete typically exhausting their energy by the end. Now, let’s apply this concept to your project:

In the context of a project, a sprint is a time-boxed execution in which teams (often scrum teams) develop and implement product features by “burning out” their efforts (measured in hours).

In this article, we will delve into the details of what a sprint means for agile and scrum teams. We will explore their characteristics, purpose, sprint lifecycle, and key elements for a successful sprint.

Brief overview of scrum

In the above definition of a sprint, we mentioned the term “scrum.” Scrum is an agile project management framework where scrum teams commit to delivering and executing a set of product features within a brief period. This process unfolds through a series of iterations that adapt to any necessary changes in the features delivered, based on market demand.

Scrum is the most popular framework in agile methodology, and the sprint is its heart. Scrum comes with several specific roles, guidelines, artifacts, metrics, and more that we won’t go into here. Product managers don’t have a specific role within the scrum team, but the relationship between a product manager and scrum teams is vital.

It’s important to clarify this relationship to maintain the proper roles and rituals of scrum. The product manager needs to be involved to ensure that the product the team is building aligns with the company’s overall strategy, but they don’t oversee or manage the scrum team directly. The product manager acts as a guide and ensures the products in progress meet the needs of the target customers.

What are the characteristics of a sprint?

So, what makes up a sprint? A sprint has:

• Definite and consistent execution period: every sprint has a fixed time period and the scrum team consistently executes within that frame. It’s rare for the team to change the duration of their sprints
• Sprint goal: the scrum team collaborates to achieve a specific sprint goal and works exclusively towards that goal
• Well-defined scope: before the start of a sprint, the scrum team has clarity on the work that needs to be carried out and the deliverables that need to be produced. According to scrum guidelines, the scope cannot be altered during the sprint
• Short duration: sprints are executed for a shorter duration, with a popular period of two weeks
• No goal altering: once a sprint goal has been decided and execution has begun, there is no authority for anyone to change the goal that the scrum team is working towards
• Predictable results: the scope of each sprint is defined, and every feature, story, or task defined by the product owner has a clear definition of done. This makes the outcome of each sprint predictable
• Zero gold plating: because each sprint is executed with a defined scope and timeline, there is no room for stakeholders to add extra features in the name of adding value to the customer or pleasing them
• Limit work in progress: sprints guide the scrum team to limit their work in progress, with each individual only having one item in progress at a time

What is the purpose of a sprint?

According to the scrum guide, the entire scrum team is responsible for creating a valuable and useful increment during each sprint. This means that the sole purpose of a sprint is to achieve the sprint goal(s).

The sprint goal is determined before the sprint begins, and all activities, such as user stories and tasks, are defined and planned to achieve the sprint goal(s). By working towards this goal, the scrum team can bring consistency and predictability to their execution, which helps them to increment value in every sprint and ultimately achieve the product goal.

Benefits of working in sprints

Working in sprints offers many benefits. By breaking down the work into smaller, manageable chunks, sprints provide a clear sense of progress and keep motivation high throughout the project. Each sprint focuses on delivering a set of features, which can be tested and refined before moving on to the next sprint.

Customers benefit from this approach too. Instead of waiting for the entire project to be completed, they can start using and providing feedback on the delivered features much sooner. This also means that the project can be delivered in shorter, more predictable increments.

Dividing work into sprints also frees up energy and allows for more focused project management. Instead of trying to manage the entire project at once, effort is concentrated on managing each sprint and incorporating customer feedback into each subsequent iteration.

Finally, working in sprints helps to reduce ambiguity within teams. Each sprint has a clear goal and set of deliverables, which helps team members to understand what they need to implement, integrate, and deliver. This helps to ensure that everyone is on the same page and working towards a common objective.

Sprint-based planning and execution benefit you with:

• Focused execution. The sprint goal and scope of work are defined and locked at the beginning of the sprint
• Increased productivity. Every team member is focusing on one task, keeping their attention on attaining sprint goals
• Increased transparency. Teams work on a common vision — they collaborate often and consistently through sprint ceremonies to discuss progress and impediments. This also helps reduce risks, as any blockers are taken care of upfront by the scrum team
• Improved morale. Indeed, everyone on the team knows what to deliver and what their role is in the execution of the sprint. Agile doesn’t enforce any organizational structure and states scrum teams as autonomous decision-making entities. This builds individual morale as each team member is valued
• Huge cost reduction. Large projects without sprint-based planning and execution would take more time (and therefore money) to launch
• Early feedback. Receiving feedback from customers and stakeholders benefits the product and enables faster releases and sprint reviews
• Capability to make changes quickly. Teams can implement change quickly based on feedback and swiftly deliver the next stable increment
• Better quality. Quality improves as the team holds sprint reviews and incorporates those changes into the product
• Higher customer satisfaction. Customers get to use features faster

The sprint lifecycle

Agile methodology is based on the PDCA cycle, where work is planned, developed, reviewed, delivered, and repeated:

Scrum and sprints follow a similar life cycle, where a series of increments are released to customers. However, there are specific events that a sprint executes as part of its process: sprint ceremonies (or scrum ceremonies):

Sprint planning

This is the first phase (event) of the sprint life cycle. During sprint planning, the product owner will go through the entire product backlog with the scrum team as per their priorities. The scrum team estimates the user stories or tasks. Based on the sprint goals defined, the user stories are picked for implementation in the current sprint.

The sole purpose of sprint planning is to create a sprint backlog that helps achieve the sprint goal. Sprint planning should consider:

• Team velocity
• Sprint goal
• Backlog items priorities

Sprint execution

This is the lengthiest phase of the sprint life cycle. The development team will implement every user story and task planned for the current sprint. The scrum team will hold a daily standup for 15 minutes to discuss:

• What was completed yesterday?
• What will be done today?
• Are there any impediments or blockers?

The scrum master will ensure the team is not blocked by any impediments that create risk for the delivery. All the activities, design, development, and testing are to be completed as per the definition of done during this phase.

Sprint review

The sprint review is the third event in the sprint life cycle. This is where the scrum team showcases the shippable increment to the product owner and other stakeholders. Typically, the team demonstrates the work completed and then reviews it during the meeting. This event occurs at the end of the sprint, usually on its final day. During the review, the product owner examines each work item with the specified definition of done and offers necessary feedback.

Sprint retrospective

The sprint retrospective is the last phase. Sometimes, scrum teams complete this event before the sprint review to help them present any concerns and notes in the sprint review itself. This is considered the last phase of the sprint, after which the next sprint would start all over again from sprint planning. During this phase, the team answers the following questions:

• What went well in the sprint?
• What could be improved?
• What will we commit to improving in the next sprint?

The team takes note of each member’s feedback and any concerns they may have during the sprint retrospective. They also jot down action items to address areas of improvement, which are then evaluated in subsequent sprints. The retrospective is considered finished when the team has successfully implemented the identified improvements in the following sprint.

Sprint rollover

During a sprint rollover, the scrum team, in collaboration with the product owner, meticulously plans each sprint. There may be instances where some work in a story is left incomplete for many possible reasons. These cases are referred to as rollovers, where the entire user story is shifted to the next sprint.

The unfinished portion of work is not delivered and is scheduled for the next sprint. Rollovers are viewed positively, as they provide insights into team velocity and allow for adjustments to be made in subsequent sprints, therefore ensuring consistency and predictable execution.

Essentials to running a successful sprint

A sprint is successful when the scrum team completes and delivers a usable increment. Several factors contribute to making a sprint successful.

As a product manager, one has to consider and work towards maintaining these factors. The goal is to help the scrum team achieve success in every sprint:

Build the right team

A scrum team has to be autonomous — independent to design, decide, and develop value as planned. A product manager has to ensure that a team is complete and that it has all the necessary resources and skills to develop and deliver a quality product.

Maintain scope clarity

A scrum team cannot live in ambiguity during execution. A product manager should make sure that the product backlog is always updated with market needs and priorities.

The sprint backlog must be clear with all requirements and a definition of done needs to be defined in each user story. Every individual in the scrum team needs to understand the user story well and know what needs to be produced.

Stick to timeframes

Any meetings (events) should always have designated times and timeframes. A product manager should always ensure the amount of time the scrum team needs for execution is accounted for. Plan with the scrum master accordingly.

Practice proper stakeholder management

To ensure the success of the product, it is the responsibility of the product manager and scrum master to invite every stakeholder for a review and obtain their feedback. Every stakeholder has an impact on the deliverables, and the scrum team works in isolation to achieve a focused execution of the sprint.

Collect metrics

The product manager, together with the scrum master, should collect and evaluate sprint metrics after every sprint.

Can only scrum framework projects execute sprints?

For me, the straightforward answer is no.

Because the sprint is the heart of scrum and is specifically designed to work together with scrum, some people only relate sprints to scrum frameworks. There is no such rule and in my opinion, a sprint is an independent process from scrum. You can execute a sprint without scrum, and you might have to add some adjustments to it. It’s possible to not use scrum terminologies and processes entirely, or to flavor it with the need of the project management methodology you will be using instead.

Think of a sprint as a process to decide on work that should be completed in a short time and be consistent in pace. So why not use the sprint process in your project execution style?

Say you are using the waterfall model and there are several phases in its SDLC. To apply sprints and benefit from them, you can divide activities in each phase, prioritize them, and create sprints. For example, in the requirements analysis, you can list all the activities that complete the phase and divide them into sprints to execute.

Conclusion

A sprint is a time-boxed, constantly-paced implementation of project deliverables where at the end of the sprint, the team delivers a usable, shippable product or increment.

A sprint always has a goal and all the activities in that sprint strictly align to meet the goal. Sprint-based teams are autonomous as they design, decide, develop, and deliver the complete product without a dependency on any external party.

We learned the many benefits of sprints and now you can apply them to your project.

Featured image source: IconScout