I recently wrote about Scrum and the ceremonies that hold it all together. The list of ceremonies can seem a little abstract when you see them as a list, when actually, Scrum is the orchestration of a whole team working together to produce a result across several disciplines.
What does it all look like in reality? Take a deep breath, here’s the flow.
The team holds a kickoff meeting for new applications or significant modules with all the developers and stakeholders on the call. This gathering motivates the developers and allows them to provide feedback to the client. Then we begin.
It all starts with the Product Owner, who determines the strategic goals and features of the application. They identify and prioritise the features in the Product Backlog, a living document containing all the User Stories and their respective Definition of Done. The Product Owner works closely with the development team, which is cross-functional and self-organising, with all the necessary skills to create a potentially releasable product increment by the end of each sprint.
The Scrum Master ensures that the Scrum process is followed correctly and facilitates communication and cooperation among the team. It's their job to keep momentum and remove any obstacles that may be slowing the team down during the sprint.
During the refinement meeting, the development team reviews each upcoming User Story with the Product Owner, who clarifies the requirements. The team discusses the technical details and makes sure they're clear on the requirements.
The Sprint Planning meeting is a time-boxed event where the development team selects the User Stories they believe they can complete during the upcoming sprint. They vote on how many story points each User Story will be, often using story point 'poker' to do this anonymously. If there isn't a consensus, the team members discuss their reasoning, and this conversation helps to uncover any misunderstandings or additional factors that may affect the story points.
The team decides which User Stories to include in the Sprint Backlog, based on the priorities the Product Owner has set, and their own estimates. They also define a clear goal for the new sprint and the User Stories needed to achieve it.
The Daily Scrum is a short, time-boxed meeting where team members report on their progress and share any challenges they're facing. The Scrum Master helps to identify and remove any impediments, ensuring that the team can focus on delivering the sprint.
At Remote, when each User Story is completed, it's checked by another team member and then code-reviewed by the Lead Developer or another senior developer. It then moves to design review, followed by User Acceptance Testing.
At the end of the sprint, the team demos all completed User Stories to the key stakeholders during the Sprint Review. This time-boxed event enables inspection and adaptation, as stakeholders either sign off each feature for release or request that the team returns it to the Product Backlog with amendments. The team regularly releases the signed-off work, usually in line with the sprint cadence.
Finally, the team participates in a Sprint Retrospective, another time-boxed event where we discuss what went well, what could be improved, and any actions we'll take to improve future sprints. This ceremony fosters a culture of continuous improvement within the team, and has massively contributed to our growth as a studio.
Each sprint runs like this, a continuous two-week cycle, with each refinement and planning session working to look ahead to the next sprint.
This takes a lot of experience, a strong process and an aligned culture to get right. When it’s right, momentum is huge. We’ve experienced industry insiders express astonishment at how much we get done in such a short space of time at Remote. This is because we’ve improved and refined this process, and, like a rugby team playing a set piece, each team member knows what to expect, when to expect it, and what to do with it.
The beauty of so much process and discipline is that it provides an arena for creativity and innovation, just as the strict rules of a rugby match allow for players to stand out and perform in ways that make crowds go wild; without those rules in place, you would have a group of people gathered on the grass, and that’s not a rugby match, it’s a park. With the rules, goals are met, momentum is built, and quality, impactful work is delivered.
This is the essence of Scrum, and this is the essence of effective software development.
