Home

Scrum Ceremonies

The Sprint, Sprint Planning, Sprint Review, Sprint Retrospective and Daily Scrum provide opportunities for transparency, inspection, and adaptation.

The Sprint

This is the center of the scrum timeline.
The Sprint is timeboxed at one month.

Consistent

Teams that adopt same-length sprints provide a regular rhythm of releasable value for the org and the client.
Predictability may emerge from consistent & short-term Sprints. The Scrum Guide requires a maximum length of a Sprint to be 1 month.

Short Term

When a Sprint is "too long", several unintended effects may arise:

  • The Sprint Goal looses its relevance. This can make the releasable increment(s) from the Sprint seem disjointed or confusing
  • Risk in releasability increases. The longer the duration a team thinks it will take to release an increment of value, the more relative room for error there will be.
  • Complexity can increase. A team may add complexity to items that were done ahead of time. A team may have mis-calculated by weeks on expected releasability of an increment.

Maintaining shorter Sprints enable a few effects:

  • Complexity can decrease. Constant consideration of a short release timeline requires tradeoffs between over-engineering to perfection, on one hand, and getting something small and irrelevant out the door.
  • Risk can decrease. When a 2-week estimation is off-target, a few days of work may be the cost. Smaller features alongside shorter sprint cycles allow for less risk when results are not met.
  • Learning can become a more regular part of the team's workflow. Sprint after Sprint, the team has built-in opportunities to review, plan, iterate, question, and learn from their work, their team, and their product.

All Encompassing

All implementations of planning, building, inspecting, adapting, and backlog refinement are encapsulated within the sprint.

Consecutive

Immediately after 1 Sprint stops, another Sprint starts. There is no down-time between Sprints.

Allow for Frequent Review Of Abilities

Lifted directly from the Scrum Guide,
"Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making."

Cancellable

Sprints can be cancelled when the Sprint Goal has become irrelevant - this can happen for several reasons.
The Product Owner is the person authorized to cancel the Sprint.

Sprint Planning

This is the start of the Sprint. Here, the work that the developers will go during the Sprint gets identified and agreed upon. The session is timeboxed at 8 hrs per one-month Sprint.

For The Scrum Team

Sprint Planning is for the Product Owner and the Developers, primarily.
The Scrum Master ensures this event happens.
The Scrum Team can invite others, and the Scrum Guide says others can attend "to provide advice".

Team Arrives Prepared

Directly from the Scrum Guide, "The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal."

Topic: Why The Sprint Is Valuable

The Product Owner leads with focus on the Product.
The Product Owner proposes to the team how value can be added to the Product during the current Sprint.
The Scrum Team, as a whole, then collabs on defining a Sprint Goal.

Topic: What can be Done this Sprint

Devs & Product Owner select items from the Product Backlog to add to the Sprint Backlog. The more the devs know about their past performance, their upcoming capacity, and their D.o.D, the more confident they can be in their forecast.

Topic: How will the work get done

Devs plan the work of each Sprint Item in order to make an Increment.

Sprint Review

The Scrum Team presents the work that has been done during the sprint.
Stakeholders hear and see progress toward the Produt Goal. Collaboration takes place regarding what will happen next for the Scrum Team.
The session is timeboxed at 4 hours per one-month Sprint.

Sprint Retrospective

The Scrum Team inspects the previous Sprint regarding individuals, interactions, processes, tools and Definitions of Done.
This session is not about the details of Product tasks. This session is about how the team does its work.
Well-executed processes are celebrated.
Misleading assumptions can be identified and discussed.
Process tooling and process roadblocks can be reviewed. Discussion takes place about problems from the previous Sprint, and how those problems may or may not have been solved. Improvements to interactions, processes, && tooling are identified.
"The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint", Lifted from the Scrum Guide.
The removal of negative processes and the refining of working processes is an implementation and Scrum expression of Lean Thinking.
The session is timeboxed at 3 hours per one-month Sprint.

Daily Scrum

This is the most frequent ceremony in Scrum.
A goal here is to gather Developers of the team on a daily basis and inspect the progress toward the Sprint Goal.
Another goal is to communicate and plan action items for the coming day of work.
Hosting this event can improve transparency, inspection, and adaptation during the working processes of the Developers.
Developers are allowed to adjust their plan any time they want, not just during the Daily Scrum. Developers opfent meet throughout the day to cover similar and more granualr topics.
The session is timeboxed at 15 minutes per day.

Tags: