First, some background context. Agile is a collection of software development practices that are characterized by close collaboration with business stakeholders, iterative development where increments of working software are delivered in short iterations (typically 1-4 weeks). Agile practices were created by experienced software practitioners who followed traditional waterfall development for many years and believed there had to be a better way to develop and deliver software.
The Scrum framework is the most common Agile methodology implemented in the United States. Scrum was inspired by case studies of product development techniques which increased speed and flexibility within the automotive, computer, photocopier, and printer industries (see Nonaka, Ikujiro and Takeuchi, Hirotaka; The New New Product Development Game). As you might have guessed, Scrum is a term borrowed from Rugby, where the team works as a unit, passing the ball back and forth, to advance down the field and score.
"Sprint Planning”, “Daily Scrum,” “Sprint Review” or “Retrospectives” are highly specialized ceremonies, each with a specific purpose. The word “ceremony” is used, because they are not your typical meeting. These are highly structured and designed to maximize the investment of the team’s time. All of these meetings are “time-boxed,” creating a constraint for the team to work within so conversations stay focused and do not get off track.
In Scrum, teams deliver software at regular, short iterations called “Sprints.” At the “Sprint planning” session, the Product Owner presents the goal of the sprint and explains the requirements that s/he has prioritized prior to the planning session. The team will discus the requirements and acceptance criteria, estimate the work, break the work down into tasks, and commit to what they can accomplish within that time frame. The session is very interactive between the team and the product owner. By discussing and estimating together, the team will often surface different assumptions about the requirements that the product owner can clarify on-the-spot. The team also aligns on the technical approach it will use to accomplish the requirements. The product owner gains a better understanding of the complexity required to accomplish the work and can re-prioritize or consider trade-offs in the scope of work / acceptance criteria to maximize the value returned by the team’s efforts. Because the team estimates and commits to the work together there is buy-in and shared urgency about meeting the sprint commitment. In a matter of hours, the team is ready to start developing against the highest priority work identified by the product owner.
The “Daily Scrum” is a 15-minute meeting where the team syncs up on their progress against the work they committed to in Sprint Planning by answering three questions:
- What tasks did I commit to accomplish yesterday and where I stand on that
- What tasks will I commit to today
- What risks/obstacles (if any) may prevent me from accomplishing this commitment to the team?
The “Sprint Review” (also known as “Sprint Demo”) enables the product owner and team to show case the work they produced during the sprint to stake holders. The team reports on whether it met its commitment and demos working software that is complete, meaning that it has met the acceptance criteria, passed testing, and considered to be “potentially ship-able.” Incomplete or partially complete work (if any) is not shown during this session. It can only be showcased in the sprint where it is completed. Stake holders will give feedback on what they have seen and may make suggestions to the product owner. Based on this feedback, the product owner may decide to change or re-prioritize upcoming work that s/he has planned for future sprints.
Having a regular inspection point at the end of each sprint, where only working software can be shown, serves several purposes:
- creates a regular rhythm for the team where there is a sense of urgency to complete the committed work throughout the entire project.
- It enables earlier feedback from stakeholders. Allows for course corrections before it’s too late in the project life cycle.
- It gives better transparency about the actual progress allowing for the right adjustments to be made.
- it emphasizes working software, as opposed to other artifacts, as the tangible value that a team delivers.
The Retrospective is held at the end of every sprint. One of the Principles behind the Agile Manifesto is: “The team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. This ceremony provides a forum for the team to be thoughtful about what went well during a sprint and what they can try to improve in future sprints. It also serves as a opportunity for team members to review any challenges internal or external to the team. The team decides what action items to take on to address challenges or get better. The retrospective encourages the team to continually improve.
I hope this post provides more clarity around what “Sprint Planning,” “Daily Scrum,” Sprint Review,” and “Retrospective” are all about. There is no mysticism around Agile Ceremonies, but they allow for teams to plan, execute, and inspect their work in a short period of time. It provides greater transparency to the progress against project objectives so that course corrections can be made earlier in the project life-cycle. Product owners and team members are better aligned because they are working more closely together. From my experience, working in this manner, can turn good performers into great teams that work closely to deliver excellent products. If that isn’t magic, I don’t know what is.