Beginner’s Guide to Agile Scrum Ceremonies and Artifacts
Scrum ceremonies are an essential part of agile development. Some of the benefits of agile Scrum ceremonies include bringing structure to the project, helping to set expectations, continuous improvement, supporting effective team collaboration, and helping to generate good project results.
Agile teams rely on Scrum ceremonies and artifacts to achieve project success. Failure to properly manage Scrum ceremonies and artifacts properly can overwhelm your project manager calendar and diminish its overall value to agile teams.
Scrum ceremonies are the fulfillment of several core agile principles contained in the agile manifesto. When an agile team decides to drop certain agile Scrum ceremonies, it is an indication that they may have also abandoned the principles the Scrum ceremony promotes.
In this article, you will learn about the 4 agile Scrum ceremonies and artifacts.
Let’s get started.
1. Sprint Planning
Sprint planning is the first ceremony held at the start of a particular sprint involving the development of objectives and execution processes within the sprint.
The main purpose of the sprint planning stage is to create all plans, documents, and frameworks according to which all processes within the sprint are executed. Decisions are made on what is to be achieved at the end of the sprint, how this is to be achieved, and by who it is to be achieved.
Sprint planning involves identifying the goal of the sprint, approving the product backlog to be used, establishing the work breakdown structure (WBS), identifying tasks, allocating resources, and assigning team members to certain tasks, among a lot of others.
The product backlog is the most important artifact within the sprint planning stage, serving as the main foundational element helping to create the sprint backlog and determine what is to be done during the sprint.
Sprint planning refers to negotiations between the product owner and development team on the best way to go about the sprint according to abilities and available resources.
The product owner states his/her intended goals through the product backlog and the development team presents the amount of effort they offer to the sprint, with all parties coming to an actionable conclusion.
- The product owner
- The development team
- The Scrum master
The length of the sprint planning stage is determined by the estimated length of the sprint. Through a form of “time boxing”, Scrum teams typically limit the length of sprint planning to 2 hours per one week of the sprint.
This means that, for instance, where a sprint is estimated to last for 1 week, meetings held in the sprint planning stage last for about 2 hours. Where the sprint is estimated to last 2 weeks, sprint planning meetings last for 4 hours.
- Focus on the Agile Sprint Goal: Focusing on the goal of the sprint rather than the expected work helps the product owner and development team come up with smarter and faster ways through which the sprint goal may be accomplished.
- Pay Attention to Established Time Box: Always take note of the established time box (usually 2hours per one week of sprint). Keeping an eye on the time box ensures that decisions are made fast and the commencement of the sprint is not unnecessarily delayed.
- Understand Your Agile Team’s Ability: Have an understanding of your team’s velocity to complete tasks before the sprint planning stage. This helps to determine the total length of the sprint and the length of sprint planning meetings.
- Identify Bugs: You need to identify bugs during this stage so they do not affect plan execution after the sprint commences.
- Take Important Note of All Scheduling Details: They include general holidays and individual time offs so you can easily plan against unavoidable absences that can disrupt the sprint.
Sprint planning particularly considers the product backlog and involves close collaborative efforts between the product owner, the development team, and the Scrum master.
The sprint planning stage is where plans are established, work broken down, and tasks appropriately assigned in the best way to productively achieve sprint goals.
2. Daily Scrum
While sprint planning involves a one-off meeting before the sprint begins, daily Scrum involves several meetings held during the sprint execution phase. Also called a daily stand-up, daily Scrum refers to daily meetings held for discussions on issues faced by team members and refreshing information on work to be done on that day.
The main purpose of daily Scrums is to clear up known issues, identify and compare individual and overall progress made on the sprint, and ensure team communication and relationship is as strong as ever.
Although product owners are expected to be present, daily Scrums are usually overseen by the Scrum master. Since they are daily occurrences, daily Scrums are kept short so that work towards sprint completion resumes as soon as possible.
Generally, discussions within daily Scrums are held about work done the previous working day, work to be done on the day the daily Scrum is held, and all present roadblocks hindering work.
Where roadblocks exist, the Scrum master comes up with solutions during the meeting. Members of the development team identify points of collaboration with other members for the day. The presence of every team member is essential and each is individually expected to contribute to discussions.
- Scrum master
- Development team
- Product owner
Time box for daily Scrums is typically set to 15 minutes. Remember these meetings are held daily, so daily Scrums are set to be as short as possible to ensure a lot of time is not wasted on talk rather than action.
Daily Scrums are also called daily stand-ups. To guarantee meetings are short, sessions are held with every individual standing. This way, no individual is too relaxed and everyone is in a rush to get comfortably seated and start work.
Admittedly, even 15 minutes seems too short for the purpose it serves. Nonetheless, daily Scrum serves as a standard time box ensuring productive use of time.
- Use a Timer: Making use of a timer is important for keeping these meetings short and within established time boxes. A timer helps make your daily Scrums as structured as the Scrum methodology generally is.
- Hold Routine and Regular Meetings: Setting up a routine by holding these meetings at the same time (preferably mornings) and location every day proves helpful. You ensure that these are constant elements of your team’s daily life, team members get used to it and are made more likely to be present.
- Organize Speakers: Getting a ball involved to indicate who speaks at the moment does not just keep the meeting organized but makes every participant attentive.
- Keep it Fun and Informative: Daily Scrums are preferably kept fun, interactive, and informative, so everyone is eager to attend. The absence of a serious tone means no one feels uncomfortable or has second thoughts on attending.
- Leverage VoIP Solutions: Where your team works remotely or is geographically distributed, leveraging VoIP phone systems facilitates attendance. The use of video conferencing software is advised as there are enough contexts for visual discussions.
- Schedule Long Conversations for Later: Longer conversations are advised to be scheduled later in the day, while relevant team members are allowed to organize themselves in relation to it.
Overall, daily Scrums are quick daily meetings mainly involving the Scrum master and development team. With them, discussions on daily team objectives and issues are identified and taken care of.
3. Sprint Review
The sprint review, also called the sprint demo, is a Scrum ceremony that occurs at the end of each sprint. Here, the development team presents work done during the sprint to the stakeholders of the Scrum project, with “work done” referring to work items that qualify as completed based on definitions by the team.
All these are showcased to stakeholders so there is an understanding of results and contributions are made by stakeholders to where changes may be applied.
Generally, the main purpose of the sprint review is to recognize the amount of value offered to the entire project and business by work completed during the sprint. The development team showcases work done while the stakeholders give feedback and indicate how satisfactory this work done is.
Sprint reviews come as either strictly structured or flexibly scheduled presentation sessions. Hold sprint reviews in an environment in which all members of the development team are comfortable, no one is on edge, and everyone easily presents all work completed without fear of immense scrutiny.
Do is to ensure that there is complete accountability from team members and there are no presentations that falsely define the actual work done due to fear. You make valuation more accurate by holding sprint reviews in a conducive environment.
- Development team
- Stakeholders, which include the end-users (customers), other senior members of management, and other external contributors
- Product owner
- Scrum master
Sprint review typically holds for 1 hour per sprint week. For instance, where a sprint lasts for one week, the sprint review lasts for one hour, and where it lasts for two weeks, the sprint review lasts for two hours.
This time length is also time-boxed so that the time spent does not exceed necessity and phases within your Scrum project remain structured.
- Make Everyone Involved Feel Important: Maintaining a celebratory feel during sprint reviews helps to accomplish its purpose, with every team member that offers value with completed work celebrated.
- Administrative Role of the Scrum Master: Ensure the Scrum master plays administrative roles that make the meeting a success. These include appropriately time boxing the meeting and making all necessary presentation materials available. The Scrum master also ensures all team members are available to give their own presentations and oversees their coordination. Stakeholders from outside the company attend the sprint review.
- Actively Gather Feedback from Project Stakeholders: The product owner is expected to actively gather feedback from the stakeholders, asking how they feel about the quality of progress made during the sprint. He or she also gives informed answers to questions that these stakeholders may have.
- Place Focus on Quality Rather than Quantity: Team members present the value work done by them gives to the entire project as opposed to the quantity of work done contributing to project completion. Doing this helps to ensure that the Scrum project comes out with astounding success in the long run and quality objectives are met.
- Include Feedback in the Next Sprint Backlog: With sprint reviews, you always look for how to include feedback in the next sprint backlog or updated product backlog. Hold deeper discussions later on these new work items and ensure that your team makes relevant improvements on sprint frameworks and processes in subsequent ceremonies.
The sprint review is a ceremony that includes every individual involved in the project. With a focus on measuring value at the end of each sprint, the sprint review intends to ensure that all completed work is satisfactory to the people that really matter.
4. Sprint Retrospective
After a sprint review comes the sprint retrospective, which is the last ceremony within a sprint and overall Scrum project. The sprint retrospective is a Scrum ceremony at the end of each sprint that takes information from the sprint review into consideration and during which areas for improvements are recognized.
You hold a sprint retrospective to come up with suggestions for improvements to be made on sprint processes in anticipation of the next sprint. The project team recognizes where things went well in the last sprint, areas where there is a need for improvement, and ways through which these improvements may be made.
Rather than feedback from stakeholders, you collect honest feedback from members of the development team. Activities at the sprint retrospective stage aim to achieve positive change where necessary. Assign processes for these changes to members of the team. Risk mitigation is also an important element of sprint retrospectives.
- The Scrum master
- The development team
- The presence of the product owner is not necessary
The sprint retrospective is typically time-boxed to 1.5 hours for every sprint week. This means that, for instance, where the sprint lasts for one week, the sprint retrospective lasts for 1.5 hours and where it lasts for 2 weeks, the sprint retrospective lasts for 3 hours.
- Collect Feedback Based on Fact: A good sprint retrospective meeting practice to collect feedback based on fact and not sentiments or how team members “feel”. This is to ensure clarity in sprint evaluation and suggestions for improvement.
- In-depth Feedback from Team Members: Feedback from team members is also expected to be as in-depth as possible. Ensure no one holds back information and has full context and information in making plans. One way of doing this is maintaining an environment where everyone feels comfortable speaking up and no one is segmented.
- Focus: Ensure focus during the sprint retrospective is placed on improvements and nothing else. Where there are subsequent sprints within the Scrum project, improvements are made for them, and where there are no subsequent sprints, improvements are made for any subsequent Scrum project embarked upon.
Sprint retrospectives involve major contributions from the development team. The Scrum master makes sure that all team members make full contributions, appropriately identifies areas for improvements and risk mitigation, and establishes procedures to make these improvements.