Sprint

Each Scrum project delivers the product in a number of iterations, which are called Sprints in Scrum. An Increment is developed in each Sprint. An Increment is a potentially releasable product. An Increment is a sum of all Product Backlog items completed so far in a project and this Increment keeps getting bigger after each Sprint. You can think of it as different versions of a software; each time with more features.

Increments may or may not be actually released (put into use), but should always be potentially releasable.

Customers usually request changes when they see the Increment (during the Sprint Review), and we note these new requests in the Product Backlog.

Duration of Sprints

Sprint is a time-boxed event, which means we should fix its duration at the beginning of the project and not change it frequently or occasionally. Sprints are fixed for one month or less.

Most companies use Sprint time-boxes of 2 to 4 weeks. If we use Sprints longer than one calendar month, it will be likely for the unapplied changes to become large enough to create problems. This will increase the complexity and risk. Sprints should not be too short either, because we would not be able to produce complete backlog items during it. Our goal is to deliver the final product item by item, inside the Sprints; we do not want to split a single Product Backlog item among several Sprints.

Focus During the Sprint

An important point is that we do not change the items of the Sprint Backlog after the Sprint is started and the plans are set (but we do change the work defined by the "tasks"). The Sprint Goal should not change either. The Product Owner and the Development Team might try to clarify and re-negotiate the scope as more is learned about the items, by changing the tasks, but will not change the Sprint Backlog items and the Sprint Goal. Even the composition of the Development Team and the quality expectations should not change during a Sprint. These constraints are designed to make it possible to focus and get things done.

Each item in the Product Backlog should normally be completed in a single Sprint as this is much easier to manage. The Development Team selects a number of items from the top of the Product Backlog (this has already been prioritized by the Product Owner) and aim to get them “Done” (100% complete) during the Sprint. We want them to be really “Done” when the Sprint is over, and create an Increment. An Increment is the sum of all the completed items during a Sprint and all previous Sprints. However, it’s OK if they are not able to deliver all items. If they are pressured to deliver everything, they will start selecting fewer items to be safe, and it will consequently lower their productivity because of the student syndrome. The student syndrome says that work expands to fill the available time.

It is important to agree on a Definition of Done at the beginning of the project. We will not call something “Done”, unless it fits the definition. A 99.999% completed item is not considered “Done”, it would not be part of the Increment and it would not be demonstrated to the customer at the Sprint Review; it will be returned to the Product Backlog and if it’s still at the top (after reprioritization), it will be selected for the next Sprint.

Events Inside the Sprint

The following are the events inside the Sprint:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Canceling Sprints

Even though Sprint Backlog items do not change, the Product Owner has the authority to cancel a Sprint. This can happen when the Sprint Goal becomes obsolete, due to changes in the Product Backlog, strategies, approach, market, etc. When a Sprint is canceled, the items that are “Done” will be reviewed and accepted, and the rest of the items (not started or partly complete) will be put back into the Product Backlog to be done in the future.

Scaling

It's best to have synchronized Sprints when there are multiple teams working on the same project, because their outputs should be integrated into one.

External Resources

• Scrum Guide, a definition of the Scrum framework by Ken Schwaber and Jeff Sutherland
• Nexus Guide, a framework for scaling Scrum by Ken Schwaber et al.
• The Scrum Master Training Manual, a free ebook on Scrum, and the Professional Scrum Master™ (PSM™ I) exam
• Scrum Awareness, a free email course on Scrum framework