Events in Scrum are used to create consistency and reduce the need for additional meetings that aren’t part of Scrum.

All events are time-boxed, so they have a maximum duration – the length of the time-box depends on the length of your Sprint.

The Sprint is essentially a container for all the other meetings and the development work. The other meetings provide opportunities to inspect and adapt the process.

The Sprint

With a maximum time-box of one month, the Sprint is where the development work is completed, with the result being a “potentially shippable software increment”.

Potentially shippable means that the Product Owner may decide that the software can be released to the customer.

However, it doesn’t have to be released.

An increment is a small slice of software functionality, that can be added on to all the previously released increments.

But how do we know if the software is in a shippable state? That’s where “Done” comes in.

Scrum team members should have a shared understanding of what “Done” is, and this should also be shared between teams.

“Done” signifies when a Product Backlog item is complete.

Example Definition of Done

Each team will have its own definition, but here’s some examples of what you might include:

• Code builds without errors
• Code peer reviewed
• Unit tests pass
• User acceptance testing passed
• Approved by Product Owner

As the Scrum Team progresses, it’s likely that the definition will become more strict.

The Sprint contains the Sprint Planning meeting, daily Scrums, development work, the Sprint Review and the Sprint Retrospective. There’s also the unofficial Backlog Refinement meeting which isn’t part of the Scrum Guide, but many teams find it useful to conduct.

No changes should be made during the Sprint that might endanger the Sprint Goal.

Sprint Goal

• A high level objective for the Sprint that is met by implementing the Product Backlog Items.
• The Team commits to the Sprint Goal rather than the PBIs.
• The Sprint Goal provides guidance on why the Team are doing the work and allows flexibility around how the solution is achieved.

Also, quality goals should not decrease, although the scope of the sprint can be clarified and altered following discussion between the Product Owner and the Development Team.

Sprints last for a maximum of one month, but you may find it useful to use a shorter time-box. Shorter Sprints allow the team to more readily adapt to changing requirements, but make sure the Development Team has enough time to create software of value.

Shorter Sprints also reduce the risk if a Sprint is cancelled – the team has only ‘wasted’ the time in that Sprint and not any more. Additionally, they allow for more frequent inspection and adaptation, enabling the team to see more consistent progress towards a goal.

Cancelling a Sprint

Only the Product Owner has the authority to cancel a Sprint, but they can be influenced by stakeholders or the Development Team.
Cancellation usually occurs when the Sprint Goal becomes obsolete e.g. the feature is no longer required.

If the work that has been completed is in a shippable state, then the Product Owner can accept it. The rest of the work is put back into the Product Backlog.

A Sprint ends when the time-box expires and the following Sprint starts immediately (In practice this is usually the next working day).

Duncan Halley is a certified Scrum Master (PSM I). You can read his blog here.

Follow him on Twitter: @duncanhalley