The sprint is the basic unit of work for a Scrum team.

And it may be the feature of Scrum that most differentiates it

from other agile models.

A sprint is a single iteration carried out by a team.

A team may complete several sprints on its way to preparing a release of software.

A sprint starts with a team committing to work to be done, and

ends with a demonstration of potentially shippable product.

While many details on a backlog item may be figured out before the team

enters a sprint, most of the work to develop and

test the feature happens within the sprint.

If you ask me to name a single feature of the sprint that is fundamental to its

success, I'd say it's when a team commits to the work to be done within the sprint.

One of the things I've learned while teaching,

is that learners are motivated and feel effective,

when they are empowered to make choices about the work they commit to.

In Scrum, the team meets for planning at the beginning of the sprint.

And, the development team members make estimates on the effort of each item.

They reach consensus on how many items they can commit to.

We'll learn more about the sprint planning event later in the course.

The length of a sprint is no longer than one month, and

it is sometimes referred to as a time box.

This means that the team is agreed.

That the sprint can't grow beyond this time limit and

everyone is committed to completing the sprint within the arrange time box.

I've worked on teams with two week and three week cycles and

I've even talked to teams that run a new sprint every week.

Each sprint typically has the same duration,

which allows the team to form a rhythm or cadence to their work.

A new sprint begins immediately after the previous sprint is completed.

A cadence helps to keep the team's momentum going and

provides a predictable pattern to the work.

The term "potentially shippable product"

is one you will hear a lot when discussing a sprint.

This is because, as declared in the agile manifesto,

we value working software over comprehensive documentation.

The idea here is that at the end of each sprint,

we will have software that has been designed, built, and tested.

The team has an agreed upon definition of done,

which you will learn about later in the course.

The sprint product may be used internally, within the organization, or

may be shipped to the customer.

Either way, the team stands behind its sprint product, and

delivers value to the organization.