Agile Ceremonies for Success

What is an Agile Ceremony?

A ceremony is a ritual that occurs regularly with a degree of formality. For an Agile team, the ceremonies are the North Start that keep the team focused and moving forward.  Core ceremonies are expected in any agile development instance. Secondary ceremonies are implemented as needed.

Core Ceremonies3885727769_1942444ba0_z






Image courtesy Flicrk Drew Stephens

Stand-ups (Daily Scrum)

What it is : A brief daily meeting intended for coordination of work done, impediment identification and synchronization.
Attendees:  Scrummaster, Developers, Product owners. Other attendees may include UX and Testers, depending on the makeup of your team. Stakeholders can attend, but the meeting is not for them, and they are assumed to observers only.
Agenda:  Capped at 15 minutes, you go around the room and  each person answers three questions. 1. What did you do yesterday? What are you doing today?  Do you have anything blocking/impeding you?
Timebox: Standups should take 15 minutes maximum.
How you know it’s working:  Successful stand up meetings are self organizing. At the start time, the team will get started, no matter who is in the room.  After standup, team members will peel off to discuss commonalities, where they are working on the same feature, or working on pieces that integrate. If the team has a seperate test group, developers will often coordinate with them after this meeting to ensure coverage. The scrummaster leaves with a list of impediments to assist on.
How you know it’s not working: Team members don’t show up, or skip the meeting. Team members answer their questions to the Scrummaster as though they are providing status. Stakeholders take over the meeting.

Off track? Get back in focus. Review the meeting purpose with the team. Disinvite stakeholders if they hijack the meeting. Ensure the team is calling out impediments and encourage them to work together post meeting.

Sprint Demonstrations/Iteration review:

What it is : at the end of the Iteration (Sprint), it is a review of all work completed within the sprint, including a demonstration of completed work for the product owner and stakeholders. (Some teams may hold an interation review for the Product Owner, then a more formal post-sprint demo for external stakeholders.)
Attendees:  Scrummaster, Developers, Product owners, Stakeholders. Other attendees may include UX and Testers, depending on the makeup of your team.
Agenda:  Show your work.  Basically a walk through of all the completed work for the Iteration, including technical debt and research stories.    
Timebox: 60 minutes for a 2 week sprint.
How you know it’s working:  The Product Owner has hands on access to the developed product and can walk through the stories, validating acceptance criteria. Technical leads can verify tech debt. Research is explained and resulting stories are written.
How you know it’s not working: Demonstration is done through screen shots and powerpoint exclusivly. Results are vague, product owners and stakeholders do not attend.
Off track? Get back in focus. Review the meeting purpose with the team. Schedule mid-Iteration product reviews to ensure deliverable work is completed throughout the sprint. Reduce velocity for a Iteration or 2 to ensure work is completed and demonstrable at iteration review.



What it is : A review and analysis of the practices in the iteration.  Basically a lessons learned  of the thing. This typically  happens between the Iteration Review and Sprint Planning.
Attendees:  Scrummaster, Developers, Product owners. Other attendees may include UX and testers, depending on the makeup of your team.
Agenda:  What worked during this last sprint, what didn’t.   There are many ways to do this. There are whole books written with ideas. (Fifty Quick Ideas To Improve Your Retrospectives or Agile Retrospectives: Making Good Teams Great  – Affiliate links)

Sample Exercise :  Draw a sailboat on the white board. Hand out post-it notes. Ask the team to write up things that made the team go faster and place them in the sails of the boat. Ask the team to write up things that slowed the team down and place them as anchors under the boat. Give the team 10 minutes to write, then read them aloud, grouping them in categories. Ask the team to vote on the anchors for the biggest problems.  Then pick the top 2 -3 items to work on during the current sprint. Assign responsible parties and review the progress during the sprint with the report out during the next Iteration review.

Timebox: 45-60 minutes.
How you know it’s working:  Teams come away with 2-3 solid improvement items each sprint. At the beginning of the new sprint the team reports on resolved issues, and enthusastically tackles new problems.
How you know it’s not working: Retrospectives don’t happen, or  improvment items languish unaddressed.
Off track? Get back in focus. Review the meeting purpose with the team. Pick 1 item to work between sprints, have the scrummaster facilite removal of the impediment. If the problem is participation from the team, try a different kind of retrospective. Make the activity for the team by the team. Have volunteers draw the boat or read the post-its. Have the team brainstorm solutions.

Iteration/Sprint Planning:

What it is : Time dedicated to planning out the new sprints worth of work.
Attendees:  Scrummaster, Developers, Product owners. Other attendees may include UX and testers, depending on the makeup of your team.
Agenda:  Review of the work in the backlog for the coming iteration. Move work from the project backlog into the Sprint backlog.

To do this the team:
* reviews the stories they are taking on
larifies acceptance critiera
*add tasks to the stories
*estimates the hours to complete the tasks.
*compares the hour estimates against the teams capactiy.
*agrees on the sprint content, and closes out the meeting with a confidence vote.

Timebox: 90 minutes- 2 hours for a 2 week iteration.
How you know it’s working: The team becomes a well oiled machine. Stories come into sprint planning well explained and need little elaboration, the team estimates their hours with greater and greater accuracy.
How you know it’s not working: It goes over time, there isn’t enough work in the backlog for the upcoming sprint. The team doesn’t participate in sprint planning or wildly under or overestimates  the  hours it will take to get work done.

Off track? Get back in focus. Ensure there is enough work in the backlog to exceed the teams typical capacity. Ensure tech leads get a preview of the stories coming into the interation so they can identify potential concerns or questions. Keep the team on track during planning with timers and online stopwatches.

Secondary Ceremonies

There are other ceremonies that teams use, some are standard technical practices, others are agile specific. These include: Mid-Sprint Demonstrations, Code Reviews, Road Map Planning, Story Grooming and Story Workshops.



Image from Flickr user Michael Carpentier