Scrum Ceremonies

Scrum ceremonies – all you need to know.

 

Scrum ceremonies overview

 

Scrum ceremonies are the key moments where the team coordinates their work, and not just for the current sprint. As a framework for agile software development, scrum ceremonies help teams deliver continuously improving products. There is also one more important thing about scrum ceremonies, and that is to ensure that type of continuity across sprints.

 

What is Scrum?

 

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum itself is a simple framework for effective team collaboration on complex products.

 

Scrum Ceremonies & The Scrum Framework

 

Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solve complex problems.  The below graphic represents Scrum in Action.

 

 

Agile Project Management Roles

 

It takes a cooperative team of people to successfully complete a project. 

 

The agile hierarchy is based on competence, not authority. The performance is not based on pleasing the boss but instead, adding value to the customer. The organization uses a dynamic horizontal and vertical communication approach that is very interactive. Ideas can come from any person in any position, including the customer.

 

Here you can find out more about agile project management.

 

It is a network that is continually growing, learning, and adapting to the constant flux; it adds new value to the customers by exploiting the opportunities presented. If done right, the continued delivery of more value to the customers through less work results in more generous returns to the organization.

Agile clearly distinguishes the differences between exploitation and exploration. In an agile organization, all members are constantly exploring ways to add more value to the customer.

During the early years of Agile Management, critics believed the small teams could never handle large, complex issues

 

Agile project teams are made up of many people and include the following 5 roles:

 

 

• Product owner

The person is responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer’s needs and priorities. The product owner works with the development team daily to help clarify requirements and shield them from organizational noise. The product owner is sometimes called a customer representative. The product owner, above all, should be empowered to be decisive, making tough business decisions every day.

 

• Development team members
  

The people who create the product. In software development, programmers, testers, designers, writers, data engineers, and anyone else with a hands-on role in product development are development team members. With other types of products, the development team members may have different skills. Most importantly, development team members should be versatile, able to contribute in multiple ways to the project’s goals.

 

• Scrum master

The person is responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator. Scrum Masters are servant leaders and are most effective when they have organizational clout, which is the ability to influence change in the organization without formal authority.

 

• Stakeholders

Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project’s outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies. For agile projects to succeed, stakeholders must be involved, providing regular feedback and support to the development team and product owner.

 

• Agile mentor

Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level. Although agile mentors are not responsible for executing product development, they should be experienced in applying agile principles in reality and be knowledgeable about many agile approaches and techniques.

 

The Four Scrum Ceremonies

 

Scrum is executed in what are called sprints, or short iterations of work lasting usually no more than two weeks. A sprint employs four different scrum ceremonies to ensure proper execution: sprint planning, daily scrum, sprint review, and sprint retrospective. These scrum ceremonies are outlined below:

 

1. Sprint Planning: In this type of scrum ceremony, sprint planning is where the team meets and decides what they need to complete in the coming sprint
   

2. Daily Scrum: When it comes to daily scrum ceremonies, this is a standup meeting or a very short – 15-minute mini-meeting – for the team to make sure they’re all on the same page.
   

3. Sprint Review: Scrum ceremonies in sprint review represent another type of meeting, but one in which the team demos what they shipped in the sprint.
   

4. Sprint Retrospective: If we talk about scrum ceremonies in sprint retrospective, then this is when the team reviews their work, identifying what they did well and what didn’t go as planned, so they can make the next sprint better.
   

 

Scrum Ceremonies & Sprint Planning

 

Attendees: development team, scrum master, product owner

When: At the beginning of a sprint.

Duration: Usually an hour per week of iteration–e.g. a two-week sprint kicks off with a two-hour planning meeting.

Agile Framework: Scrum. (Kanban teams also plan, of course, but they are not on a fixed iteration schedule with formal sprint planning)

This ceremony helps to set up the entire team for the coming sprint, creating a smooth pathway for a successful sprint. Sprint planning requires the participation of all the scrum roles: the development team, scrum master, and the product owner. The planning, of course, is prior to the sprint. It typically lasts for an hour or two. 

The product owner comes to the meeting with a prioritized list of the product backlog items, which is presented to the group. The items on the list, which are also called user stories, are then discussed with the development team. Together, they estimate what it will take to complete the items on the list. From this information, the development team makes a sprint forecast. They will outline how much work the team can complete from the product backlog. This will be known as the sprint backlog.

Some sprint planning ceremonies will flesh out details of each user story. This will make sure that everyone involved understands the scope of the work. Though, some will have a separate story refinement meeting or ceremony. By doing this, the actual sprint planning ceremony is shorter and directed only towards user stories that will be tackled in the upcoming sprint.

 

Daily Scrum Ceremonies

 

Attendees: development team, scrum master, product owner

When: Once per day, typically in the morning.

Duration: No more than 15 minutes. Don’t book a conference room and conduct the stand-up sitting down. Standing up helps keep the meeting short!

Agile Framework: Scrum and Kanban.

This short scrum ceremony makes sure that everyone knows what’s happening. It’s a way to ensure transparency across the team. This is not the time to dive into the weeds. A detailed status meeting is not, but rather a light and fun informative meeting. It’s a space for each team member to answer the following questions: what did you complete yesterday, what are you working on today, and are you blocked by anything? 

The daily scrum is, as it says, a daily occurrence, which usually takes place each morning with the development team, scrum master, and product owner. The ceremony is short, usually 15 minutes, which is why it’s also called a standup meeting. That will make sure it doesn’t drag on.

The great thing about the daily scrum is that it demands accountability. People report honestly on what they did, what they plan on doing and how they might be getting blocked in the process, and this is all done in front of their peers. Having to report in such a social setting sets up the team for success because it would be embarrassing to not be showing progress in front of others. The daily scrum is not limited to teams that share a physical location. If the teams are working remotely, the ceremony can be conducted with video conferencing or another group chat.

 

Sprint Review

 

Attendees: development team, scrum master, product owner

Optional: project stakeholders

When: At the end of a sprint or milestone.

Duration: 30-60 minutes.

Agile Framework: Scrum and kanban. Like planning, review for kanban teams should be aligned with team milestones rather than on a fixed cadence.

After the sprint has been completed, it’s time to get the team together to demo or showcase their work. Each team member reviews the newly developed features or whatever it was that they worked on during the sprint. This provides a space for the team to congratulate themselves on a successful sprint, which is important for morale. It also demonstrates the finished work for the entire team, so they can provide feedback and also get feedback from the stakeholders in the project. 

Here, unlike other ceremonies, the review can last as long as it takes to demo all the work done by the team. Again, the participants are the development team, scrum master and product owner, but also in this instance, other teams involved in the project and the stakeholders. 

These demos are not partial but a full review of the work. If not, then the point of the sprint review is diminished. The reviews must meet the quality level set up by the team or they’re not considered complete and shouldn’t be demoed in the sprint review.

 

Sprint Retrospective

 

Attendees: development team, scrum master, product owner

When: At the end of an iteration.

Duration: 60 minutes.

Agile Framework: Scrum and Kanban. Scrum ceremonies teams do sprint retrospectives based on a fixed cadence. Kanban teams can benefit from occasional retrospectives, too.

The last scrum ceremony is called the sprint retrospective. It occurs at the end of a sprint, after the review, and is usually an hour in duration. The retrospective includes the development team, scrum master and product owner. 

Because scrum ceremonies are part of an agile process, it is all about change, which includes getting feedback and quickly acting on it. Scrum ceremonies seek continuous improvement and the retrospective is a method to make sure that the product and development culture is constantly improving.

The retrospective is a way for the team to understand what has worked well and what didn’t come together over the previous sprint. The post-mortem exposes fault lines in the team and its process, so they can buttress those weak spots and approach the next sprint in a stronger form. 

This is not a bull session in which talk doesn’t go outside of the meeting. It is a place for a talk that leads to action. Team members are discouraged from complaining or criticizing without everyone working together to resolve those issues.

The sprint retrospective isn’t a blame game but a means to identify and rectify issues that have come up over the course of the sprint. It is also an instrument to congratulate the team on a job well done when there were no issues. But, if the mantra of scrum is to always seek to improve, then the retrospective must be critical, too, but only as a stepping stone to improvements. Constructive criticism is key here.

 

Scrum Ceremonies in a Remote Environment

 

 

Now we are going to talk about scrum ceremonies and remote work. Remote work is all around you, and it’s great! But, as it’s widely commented in the agile community, it poses some specific challenges when implementing scrum ceremonies or other agile approaches.

Scrum and scrum ceremonies does not mention co-location at all. One of the Agile Manifesto Principles states that The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. As a fan and promoter of remote work, I don’t disagree. Face-to-face conversation in the most efficient and effective. But it’s not the only option and often our remote options are the best ones in the given context.

 

Diagram Copyright Alistair Cockburn

 

A lot of common techniques of agile can’t be copied from F2F to remote environments, thus agile in a remote environment can be harder to create and maintain.

A remote environment can let mature agile teams thrive, while it can make less mature, less self-aware teams struggle. The challenges are real, and after overcoming them remote agile can be even more powerful than a collocated setup – when you minimize the downsides and harness the advantages to the maximum.

 

Building an agile team in a remote environment

 

The process/framework is always deeply connected to the Agile Manifesto and its principles and is usually strongly inspired by the Scrum Guide. Building an agile team in a remote environment is a combination of two big challenges – being agile and building a team. Below I’d like to focus on the challenges that are especially common when you combine those two.

 

Two most important tips: 

• Set aside some time for reality checks of communication and transparency, especially at the beginning of your team’s journey. In a remote environment, it’s easier to miss some red flags. 
• Experiment with translating exercises and activities to a remote environment.

 

Want to use a technique you know from on-site meetings? 

 

It’s often possible – think about how the technique uses elements of the physical environment, and how can you achieve it online. Use online whiteboards, shared documents like Google docs, and video calls (ex. you can split a 12-person call into four 3-person calls for work in groups).

 

Common challenges in managing remote teams

 

It’s extremely easy to slide into the chaos realm when dealing with software projects. So many options in virtual space, all those decisions that are not yet made, and all the changes that will surely come. 

How to deal with that? The answer is a flexible structure. 

A good example of such a flexible structure is the Scrum framework. It lays out some must-haves and leaves you space to fill it with content suitable for your product. Naming team rules and flow explicitly is key for agile approaches, like the kanban principle – visualize the workflow.

 

Building trust

 

The first steps may be hard, but when you focus on promoting self-reliance and maintaining transparency you have all the foundations you need. Building trust is crucial for effective collaboration. 

Focus on building trust both inside the technical team and between the technical team and the client or whole business team on the client-side. We need transparency between development and business to make sure we are building the right thing. And we need openness inside the team to make sure we build it the right way.

 

Self Reliance & Self-Regulation

 

Remote work requires maturity. Each team member needs to be able to take responsibility for their work environment and take ownership of their work’s organization. Just like in agile work. Being a member of a self-organizing team requires first taking ownership of your work, and then expanding it to the whole team. Trust, self-reliance of team members, and the self-organization of the team are interconnected. 

You have to build on all those qualities incrementally – more trust means more space for self-reliance. Self-reliance and self-regulation of the team is an important topic both in remote and in agile work. When building agile in a remote environment this challenge is even more important, because both the cost of the failure and the payoff from success are doubled.

 

The project manager’s role in managing remote teams

 

Every new team needs to find its structure to avoid chaos. The first task when starting a new project is to help with that first, basic structure. Then focus on building trust and transparency to make sure we are building a real team, around a common goal, and not just having a group of great specialists, each focused on their own mini-silos.

When the team is working inside this first frame, the next challenge begins. During this process, the team starts to take ownership of the frame they were given and adjust it to their needs – step by step they create new team rules, influence each other’s behavior, and learn from each other. The job of a Project Manager, or of a Scrum Master, implies being with them and helping them with their transition and adapting to changes they encounter.

 

Remote work environment tips

 

Being agile in a remote environment is definitely possible, but can be challenging. You will have to focus both on all the challenges of building a team and the challenges of organizing remote work.

Remember to:

1. Name your values. You need to understand your values first to make sure you share them with the whole team. Scrum Values are a good starting point for remote team values: Courage, Focus, Commitment, Openness, and Respect. 
2. Meet with the team daily. Make sure to cover not only technical topics. You want the team to work out their values in practice – give them space to do that. A good start is to write down an agreement inside the team – a team contract where you will discuss how you plan to work and hold each other accountable. 
3. Look out for communication gaps and conflicts. It’s easier to avoid unpleasant topics in a remote world and it’s harder to give feedback. Start with yourself – give small feedback, both good and bad, right after every call, every encounter.
4. And in the end – remember to leave the team space to learn from both successes and failures. You are not there to shield them from everything. Step by step, they should be able to handle more chaos themselves and become less dependent on your support.

 

Adapting agile to a remote environment is the next big step for the agile community. It’s already happening in a lot of organizations worldwide and it’s a big challenge for every team and every organization.

 

Articles that we recommend:

• What is agile project management?
• Management Skills and Tools for the New, Changing Economy
• Trello Vs Asana

 

Feel free to find out more about me.

 

Sources

1. https://www.netguru.com/blog/how-to-deal-with-agile-scrum-in-a-remote-environment
2. https://www.scrumalliance.org/
3. https://thedigitalprojectmanager.com/
4. https://devqa.io/
5. https://usefyi.com/
6. https://www.dummies.com/careers/project-management/agile-project-management-roles
7. https://www.agilebusiness.org/page/ProjectFramework_07_RolesResponsibilities