If you’ve ever attended meetings where you wondered why you were there and what value any outcomes might have, then you’ll understand why meetings in Scrum are called ceremonies. Ceremonies are regular events that have a set agenda and outcomes that are easily understood.

Daily Scrum AKA Daily Stand-up

The Daily Scrum is a short meeting, (usually 15 minutes,) attended by all in the delivery team aimed at communicating progress, resolving impediments and refocusing effort. The daily stand-up is a short meeting attended by all in the delivery team aimed at communicating progress, resolving impediments and refocusing effort.


  • Delivery Team
  • Scrum Master
  • Product Owner

Whilst any other stakeholders may attend the stand-up, and indeed it is often the best way for them to keep informed of how work is progressing, only the delivery team members may speak.


At a stand-up, progress reports are given by each team member answering only the following 3 questions:

  1. What I worked on since the last stand-up
  2. What I will work on until the next stand-up
  3. Any impediments in completing my current tasks

As the name suggests, an important element of the stand-up meeting is that everybody stand, the idea being that each report will be briefer if people aren’t too comfortable.


The Daily Scrum results in a team refocused on the tasks at hand and better able to collaborate on solutions.

Sprint Planning

The Sprint Planning meeting is a time boxed event, (usually 1 hour for each week of the sprint,) aimed at defining, designing and planning for the “Sprint Backlog”. Sprint Planning is often broken into 2 separate phases, phase 1 selects the stories the team will commit to delivering during the next sprint, while phase 2 focuses on the design of those stories, how they will be delivered and the tasks required to deliver them.

Phase 1:

Phase 1 of the planning meeting is when the Sprint Backlog is selected which also becomes the Sprint Commitment, which involves the team making a firm commitment to completing the stories selected.


  • Delivery Team
  • Scrum Master
  • Product Owner
  • Invited Subject Matter Experts


At Sprint Planning, (Phase 1,) the team work with the Product Owner and invited SMEs to go through each story in the backlog in priority order to ensure the team has a good understanding of the requirements. The Scrum Master will bring the latest understanding of the team’s velocity, (averaged over the previous 5 iterations,) and any resource impacts planned in the next iteration, (annual leave, public holidays etc.) As the team review each story, the number of “Story Points” is estimated based on relative complexity.

The team continue to work through the stories in the backlog until the total of their estimates, reaches their current velocity, those estimated, committed stories form the Sprint Backlog which becomes the team’s commitment for the next sprint.


The “Sprint Backlog” (the list of stories that will be delivered in the upcoming sprint.)

 Phase 2:


  • Delivery Team
  • Scrum Master
  • Product Owner

At Sprint Planning, (Phase 2,) the team work through the stories selected for the next sprint in the Sprint Planning, (Phase 1,) meeting defining the tasks necessary to deliver those stories and any design approaches they will take.

The Product Owner is included so that they can provide any further detail on what is required for each story and to agree or not to any compromises to business outcomes that may result in any design decisions that the team make.  Should a design choice lead to a compromise in the outcome, only the product owner can approve that design decision.


Each story is again reviewed and design considerations discussed. Task cards are created for each of the tasks that will be required in order to deliver on the story to the agreed design. Estimates are assigned to each task card based on the amount of time required to complete that task.  While stories are estimated based on relative complexity, tasks are estimated based on time.


The Sprint Backlog from Sprint Planning Phase 1 with design documented and all the tasks necessary for a successful delivery defined.

Sprint Review AKA The Showcase

The Sprint Review presents the solutions delivered in the iteration to the Product Owner and invited SMEs to confirm that they do indeed meet the requirements and are acceptable, (can be called “done”.)



  • Delivery Team
  • Scrum Master
  • Product Owner
  • Invited Subject Matter Experts


At the Sprint Review the facilitator, (often the Scrum Master, but many teams will rotate this position,) or one of the team responsible for delivering the story being reviewed will revisit the story card, with the Product Owner and SMEs, paying particular attention to the acceptance criteria defined.

With the story and its acceptance criteria clearly articulated, the team present the completed solution to the Product Owner and SMEs seeking their acceptance that the delivered solution meets the acceptance criteria requested.

Unless the story somehow fails to meet some aspect of the acceptance criteria, the Product Owner really should accept it.  If there is any element of the delivery that does not meet the acceptance criteria, then the story can still be accepted, (if the failing is inconsequential,) but only the Product Owner can determine this.  If the story is not accepted, then it may need to be taken out of the sprint and returned to the backlog.

The reviewed story is discussed and any impacts on the backlog are applied, (sometimes it is only when the Product Owner sees the final solution that they realize an element was missing or miscommunication in the original story, this should not equate to the delivery failing, but instead can become a new story in the backlog to make whatever adjustments arise.)


The delivered stories are accepted and final acceptance testing and release planning can occur.  Failed stories are returned to the freshly re-ordered backlog in readiness for the next sprint.

Sprint Retrospective

The Sprint Retrospective is the team’s opportunity to review how well they’re working and refocus efforts in the next iteration towards continuously improving quality and quantity of their deliverable and effectiveness as a team. The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.  This is a one-hour per week of sprint time-boxed meeting.  The Scrum Master ensures that the event takes place and that attendants understand its purpose.  The Scrum Master teaches all to keep it within the time-box.  The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.


The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements;
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of ‘Done’ as appropriate.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation. The context of the Retrospective sets out the focus and approach for that Retrospective. (See Agenda section below)

Important aspects of facilitating a retrospective include:

No personal or directed for single member:

Discussion of the difficulties or outcomes from a story are acceptable so long as it doesn’t become a blame seeking event. There should be no comments like ‘he did …’ or ‘she should have…’. You can achieve this by always keeping the Prime Directive in mind.


‘Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.’

Regardless of the Context for a Retrospective, the Prime Directive is a statement that sets the stage for the retrospective and ensures the activities, discussions and outcomes are aimed at maximum benefit for the team.

If teams repeatedly fall into blame or personal comment, it may be necessary to print out the Prime Directive and post it prominently on a wall visible to all participants.

Ensuring everyone has an equal voice

It is important for the facilitator of the retrospective to balance the discussion and ensure everyone has an equal voice.

If someone is speaking significantly more than the rest of the team, ask them to help eliciting responses from others, ‘Thanks Johnny, it’s good to hear your enthusiasm for that point, could you please own the discussion of that for a while and ensure we’ve got an equal and balanced input from all the team members.’

If someone is not speaking at all to issues, encourage them to speak up, ‘What are your thoughts on this item Sally?’

Ensuring an outcome is identified.

Outcome should be actions or behaviours that the team can adopt that will enable better outcomes in future sprints. Ideally there will be a small number of outcomes so that they can receive the focus of the entire team, too many outcomes may mean that none of them receive adequate focus and no improvements are realised.

Follow an agenda.

Whilst there is a great deal of flexibility in the agenda you may choose to follow, the main items should always be included:

  1. Review and discussion of the sprint commitment(s) from the previous retrospective to arrive at an understanding of how well they have been implemented and how effectively the issues addressed have been resolved.
  2. Information gathering.  This step gathers the inputs to the retrospective discussions.  Inputs from the team can either be collected prior to the retrospective, or shouted out during the meeting itself, either way, participants should be encouraged to arrive at the meeting well prepared with their individual inputs.  There are many formats to choose from, a few suggestions include:
    1. WWW
      • What worked well?
      • What didn’t work well?
      • What can we improve?
    2. Stop/Start/Continue
      • What will we stop doing
      • What will we start doing
      • What will we continue doing
    3. FLAP
      • Future direction
      • Lessons learned
      • Accomplishments
      • Problem areas
    4. Process FMEA (Failure Mode and Effects Analysis)
      1. Analysis
        • What was the failure?
        • What led to the failure?
      2. Evaluation
        • What are the consequences of this failure?
        • What is its severity?
        • What is the probability it will happen again?
  • Action
    • What corrective or preventive actions will ensure it doesn’t happen again?
  1. Verification
    • Given the listed actions, how can we verify their outcome?
  2. Hot air balloon
    • What gives us lift?
    • What weighs us down?
  3. Discussion of the items raised
    1. Review of each item listed, what the inputs were to that item, what were the outcomes of that item, what was the impact on the team and the teams ability to deliver in the previous sprint.
  4. Voting for the priority items to focus on
    • . Which of the items listed during information gathering are the most important for the team to address?
      • There are various ways to gather these votes:
        • One vote per person per category, Each team member identifies their highest priority items in each category.
        • Dot voting, Each team member has a specified number of dots that they can put on any number of items, (they could put them all on a single item if they so choose.)

Hope I have covered all the points related to scrum ceremonies. Still if audience think that something is missing, please feel free to put your thought in comment section.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>