Sprints in Agile & Scrum: Definition & Methodology

Instructor: Stephen Meyer

Stephen has worked as a Project Manager and is PMP certified, as well as certified by the Scrum Alliance.

One goal of Agile and Scrum is to produce tangible results and receive feedback as early as possible. This cannot be accomplished through an extended, linear timeline but requires a breakdown into short, repeated sprints. Learn the definition and methodology of sprints in Agile and Scrum.

Definition and Purpose

Sergey has been helping his team transition to Scrum, the most common form of Agile project methodology. They like the concepts of receiving feedback earlier and responding to change better. However, as Sergey has moved into the specifics of implementing Scrum, the team is having second thoughts. After years of deadlines, the team is suspicious that sprints are actually a condensed timeline in which they will have to complete all the work sooner. Sergey attempts to define sprints, as well as help the team understand how sprints are executed and used, so that that they can see the benefits.

A sprint is a repeated interval, typically two to four weeks, into which the project timeline is broken down. This is important in easing the concerns of Sergey's team: a sprint is not a condensed project timeline, but a portion of it. Within a sprint, the expectation is that smaller, functional portions of project work, known as user stories, can be fully developed and tested. The expectation is not that all project work will be completed during a single sprint.

The concept of a sprint is at the heart of Scrum. The goal is to produce a tangible result and receive feedback on it as soon as possible. This is in contrast to more traditional methodologies where all development is completed, then all testing is completed, and then the work is reviewed. Breaking down the project work and project timeline into smaller pieces is what allows the goal to be accomplished. The sprint is key, though, because breaking work down into manageable pieces loses its value unless the work can be completed in a shorter time frame as well.

Methodology

After Sergey defines sprints for his team and helps them understand the purpose, he then moves on to how they execute a sprint. Executing a sprint successfully will help his team receive the most benefit from it. Sergey breaks down the execution into how the sprint begins, how it progresses each day, and how the sprint ends.

Each sprint begins with a meeting called the sprint planning meeting, which is where Sergey's development team reviews user stories and assigns each a numeric point value as an estimate of the time and effort to complete it. They commit to completing user stories that have an estimate point total equal to the number of points they typically can complete within a sprint. User stories are kept in prioritized order for the project as a whole in the product backlog. They move to the sprint backlog once the team takes them into the sprint, where they remain in prioritized order for the team to work on them. The sprint planning meeting is when user stories move from the product backlog to the sprint backlog, and is what sets up the entire sprint. This is important to Sergey's team because they take on a portion of project work, not all of it.

The sprint progresses in two ways. The first way is through the completion of project work. As each user story is completed, the sprint comes closer to completion. The second way that the sprint progresses is through a daily checkpoint meeting for the team, known as a daily Scrum. This is a brief meeting where Sergey and his team discuss work that has been completed, how the remaining work will progress, and if there are any issues that are impacting the sprint.

Once each user story is completed at the end of the two or four weeks, the sprint comes to an end. Any work that is incomplete is considered carryover and moves to the next sprint.The end of a sprint is marked by two meetings, the first of which is known as the sprint review meeting. In this meeting, Sergey and his team review the product of the user stories with the Product Owner, who requested the project work, and other stakeholders. Once the user stories are reviewed and accepted, the sprint is considered complete. This is also where any additional feedback is given. If a user story is not accepted because it was not completed or does not meet what was requested, it is carryover and will be worked on in the next sprint. On the other hand, if it is not accepted because the request has changed, a new user story should be written to describe the new request and the current user story should be approved.

The second meeting that marks the end of the sprint is called the sprint retrospective. This is where Sergey and the team discuss the past sprint. In particular, they discuss the things that went well, the things that did not go well, and ways to improve. The goal is to make the next sprint more efficient and more effective. This is one aspect of the iterative process, where, as one sprint ends, the focus becomes improvements for the next sprint.

Sprint

To unlock this lesson you must be a Study.com Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use Study.com

Become a Study.com member and start learning now.
Become a Member  Back
What teachers are saying about Study.com
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account
Support