sprint (software development)

Contributor(s): Vicki-Lynn Brunskill

In Agile product development, a sprint is a set period of time during which specific work has to be completed and made ready for review.

Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria need to be met for the work to be approved and accepted.

The duration of a sprint is determined by the scrum master, the team's facilitator and manager of the Scrum framework. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Traditionally, a sprint lasts 30 days.

Content Continues Below

After a sprint begins, the product owner must step back and let the team do their work. During the sprint, the team holds daily stand-up meetings to discuss progress and brainstorm solutions to challenges. The project owner may attend these meetings as an observer but is not allowed to participate unless it is to answer questions. (See pigs and chickens). The project owner may not make requests for changes during a sprint and only the scrum master or project manager has the power to interrupt or stop the sprint.

At the end of the sprint, the team presents its completed work to the project owner and the project owner uses the criteria established at the sprint planning meeting to either accept or reject the work.

Sprint roles, artifacts and ceremonies

A variety of roles are involved in a sprint, with each working on different parts of the process. These roles include:

  • Product owner: This person represents the business or user community and is a liaison between the development team and customers. The product owner is in charge of working with the user group to define, prioritize and adjust what features will be in the product release. They also accept or reject work results and keep customers upraised of the project’s status.
  • Scrum master: This person is the main facilitator for the project’s development team. They manage the process for how information is exchanged during the sprint, including leading stand-up meetings and helping the team stay on track by mediating problems and removing obstacles. Their main focuses are transparency, observation and organization.
  • Scrum team: This group of people is responsible for executing the work. In addition to developers, the scrum team can contain testers, architects, designers and IT operations While the scrum master is charged with protecting the team and keeping focus, the team itself is self-managed and ultimately responsible for collectively determining how to reach their goals.

Artifacts provide the information that a scrum team needs to understand the product under development, as well as completed and planned activities for the project. Artifacts include:

Ceremonies are meetings that are held for every sprint. Ceremonies include:

  • Sprint planning meeting
  • Daily scrum or daily stand-up meeting
  • Sprint review
  • Sprint or Agile retrospective

Sprint workflow and process

The sprint workflow is intended to help team members evaluate their work and communicate with each other throughout the entire process. The workflow is followed for each sprint. The process includes:

  • Backlog - A list of set tasks that must be completed before the product is released. The backlog is built by the product owner. The product owner gives a backlog of prioritized items to the scrum master and scrum team. The backlog is based on user stories, which focus on features that consider the type of end user, what they want and why.
  • Sprint planning - The team discusses top priority user stories and decides what can be delivered in the sprint.
  • Sprint backlog - Agreed upon by the entire team, this list finalizes and defines what the development team will complete during the sprint.
  • Sprint – The time frame in which the work must be completed – often 30 days.
  • Daily scrum – Lead by the scrum master, the team comes together for short daily meetings, in which they discuss what they have completed, what they are working on and any issues that are blocking the work.
  • Outcome - The outcome of a sprint is a hypothetically usable product. The product owner can decide if the product is ready or if additional features are needed.
  • Sprint end - At the end of a sprint, two meetings are held:
    • Sprint review – The team shows their work to the product owner.
    • Sprint retrospective – The team discusses what they can do to improve processes. An important goal is continuous improvement.

Scrum vs. sprint

Scrum is the specific, framework used under the Agile umbrella to develop complex products. The term scrum is also used to describe the daily, standup meetings that occur during a sprint.

Sprints are time-boxed periods of one week to one month, during which a product owner, scrum master, and scrum team work to complete a specific product addition. During a sprint, work is done to create new features based on the user stories and backlog. A new sprint starts immediately after the current sprint ends.

Scrum productivity tools

Today's marketplace offers a multitude of scrum productivity tools. Each is designed to help product development teams follow the scrum/sprint methodology efficiently and accurately.

Popular scrum tools include:

  • Jira
  • nTask
  • QuickScrum
  • ScrumDo
  • Scrumwise
  • Vivify Scrum

Benefits of scrum sprints over traditional development

While there are many software development methodologies, such as rapid application development (RAD) and DevOps, most of today’s development teams use either Agile or the waterfall model.

The waterfall model is a software development methodology that originated in the 1950s and is often referred to as ‘traditional’ software development. The waterfall model tackles projects in a linear, sequential manner based on distinct phases:

  • Requirements
  • Analysis
  • Design
  • Coding/implementation
  • Testing
  • Operation/Deployment
  • Maintenance

These phases are siloed, each dependent on the completion of the phase before it, and include little or no user feedback until the final phase. Some Agile advocates claim that the waterfall model leaves few opportunities for design adjustments mid-process, which can disrupt the development workflow and delay product delivery.

Scrum sprints are more collaborative and adaptive than waterfall phases because sprints break software features and requirements into iterations to be tackled during short time periods. With frequent testing, immediate feedback, daily meetings and ongoing input and consideration of end-user stories and needs, sprints result in products with extremely relevant features.

Agile proponents also report that sprints offer improved time to market, faster ROI, greater customer satisfaction, improved team morale and better project control.

This was last updated in August 2019

Continue Reading About sprint (software development)

Dig Deeper on Software project management

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

The product owner is the only person that can decide to abort a sprint. The scrum master or project manager cannot, since it is not their money being spent.
@TJP Thomas; I don't think the bit about stopping or interrupting the sprint is as much about aborting as it is about managing the team's time. Business needs sometimes seem to oscillate quickly, and if the product owner has the power to redirect the team's focus mid-sprint (by aborting the current project and restarting a previously aborted project) it ties the scrum master's hands too much and doesn't give the team enough self-reliance.
Of course there should be an emergency break where the product owner can totally scrap a project, but ideally that would be pulled in between sprints and would only happen if the project is totally unproductive (which shouldn't happen if the product owner is committed to their role in the beginning).
I think this need for the product owner's commitment is why I tend to see more 2-week sprints than full-month sprints. It's easier for the product owner to fund two weeks of work at a time than to commit to not changing direction for a full month.
Wow, sound good. I think sprint is best but not as best like agile. In agile methodology each and every phase is defined first. even if you want to change developer or development company still you will not loose any thing.
The duration of a sprint is determined by the scrum master, the team's facilitator - This is a wrong statement. Sprint length is determined by the entire team i.e., PO, SM, DT
There are several things here at variance with the Scrum Guide, both to the letter and the spirit.  A couple of things:

The Product Owner is the only one that can cancel a sprint, thought they might be under the influence of stakeholders or the team.

The Product Owner is not the requester of the work, that is a far too transactional view.  They are the owner of the backlog items and assists the team by expressing and ordering them.

It is not true that there must be no changes during a sprint, just not any that endangers that the sprint goal.  Ones that enhance it are positively encouraged and is the whole point of making progress transparent.  It is then inspected and if necessary adapted.  

Therefore the more remote the Product Owner, the greater danger that the solution diverges from that which can provide the greatest value.  

A thought provoking article, but let down by a some misunderstandings and a very mechanistic interpretation of Scrum specifically and agile in general.
Nice article. In my opinion following strict Agile methodology is practically not possible to start with.  You need to overcome lot of hurdles to follow an ideal Agile methodology.  Since we are new to Agile, we follow quasi agile where we tailored many things as per our convenience and to a certain extent we are successful.  The developer team can't be utilized for more than 2 projects (max) if you are planning to follow agile methodology.  We need exclusive testing resources too as part of the scrum team. Hence it's best fit for a mid and large organizations.

File Extensions and File Formats

Powered by: