Scrum Ceremonies: Daily, Planning, Review, and Retrospective Meetings
What are scrum ceremonies?
Scrum is a framework for organizing work in a team. We use scrum ceremonies to organize all software development and course content creation at Cognitive Class.
Scrum is well suited for agile software development. It’s possible to use scrum to organize other kinds of teams. For example, The Rhesus Chart is a fun Sci-Fi novel by Charles Stross about a coven of vampires using Scrum to take over London. For now, my scrum experience is focused on software development.
Agile software development is a fuzzy term that encompasses everything that’s not waterfall software development; waterfall being a multi month cycle of planning-developing-testing with discreet stages. Scrum is a specific, iterative way of doing agile.
Scrum is composed of several scrum ceremonies:
- Daily standup
- Review or demo
Scrum is important both from a task-management perspective — what will I accomplish today? — and a project management perspective — when will the feature be finished?
Who am I?
My name is Leons Petrazickis and I am a Platform Architect for Cognitive Class. Cognitive Class is an educational site that let you take free online courses in data science and AI at your pace and at your place. Course completion is rewarded with badges and recognized with certificates backed by IBM. Many courses have hands-on labs, and the technical underpinnings of that lab environment is my area of specialty.
We use scrum ceremonies at Cognitive Class both for organizing our software development and for organizing our course content creation.
I’m fifteen years into my career as a developer or, as they say in California, engineer. I’ve built a lot of cool things. In the context of our scrum, I am the Scrum Master.
Our team has many developers, data scientists, and paid interns. Scrum ceremonies have helped us organize our work and deliver results.
Who are the stakeholders in scrum ceremonies?
There are three types of contributors in scrum:
- Individual contributors.
- The scrum master, who acts as a mentor.
- The product owner, who insists on business value and deadlines.
Older descriptions of scrum divided people into pigs and chickens. Pigs have a lot of stake in a project and chickens contribute occasionally. All three above are pigs in that sense.
Planning and scheduling as scrum ceremonies
A key component of scrum is breaking up work into small chunks. If a feature is going to take more than two weeks to implement, it doesn’t fit in a scrum context. You need to break it up into smaller, self-contained features before you can start on it.
Once you have a backlog of small features, you can schedule and assign them into 1-week or 2-week sprints for your team. It is seldom sensible to plan more than one sprint in advance. As Helmuth von Moltke observed, no plan survives contact with the enemy.
Low tech is often best for managing a small backlog. There are many software tools for planning work, but the closer the tools are to post-its on a whiteboard, the more effective they will be, at least from a task management perspective. Post-its on a whiteboard are less valuable from a project management perspective which is more concerned with due dates and velocity of work.
A feature has to be described as a user story. Purely technical tasks aren’t stories, nor are simple bug fixes. A story takes the following format:
As a [role], [name] needs [feature description] in order to [benefit description].
As a data scientist, Alice need a visualization library in order to communicate the key data in her reports to executives.
As a miser, Ebeneezer Scrooge needs three ghost visits in order to learn to be a nicer person.
Daily standup as a scrum ceremony
The daily standup can be eponymous with scrum itself — often we just call it the scrum.
The reason it’s a “stand” “up” is because people who are standing are uncomfortable and so less likely to ramble about unrelated topics. Stands ups have to be quick to not waste people’s time. There’s rarely a true need for someone to say more than three sentences in a standup.
The traditional standup consists of every person speaking in turn and answering these three questions:
- What did I accomplish yesterday?
- What will I accomplish today?
- Am I blocked by something?
An important phrase to remember for a scrum master: “Let’s discuss that AFTER we finish the stand up.”
As a scrum master, my role is to mentor everyone on the team. The scrum master should help individual contributors get past any roadblocks, as well as recognize architectural, security, technical and other challenges in work descriptions.
This year my focus has shifted from scrum being used to organize developers working on a shared project to something more like a Scrum of Scrums being used to organized our interns each working on their own individual project. There, another question becomes important:
- When will I finish all my work in this sprint?
“Finished” is a contentious word. To a developer, “finished” can sound the same as “development-complete”, but that doesn’t finish the user story. “Finished” means “available to the person named in the story”. Your feature is not finished until it’s available in all the production environments to all the end users.
Review as a scrum ceremony
One way to prove that a new feature that you delivered is finished is to demonstrate it to the rest of the team. The more unconnected everyone’s projects are, the more important it is to have regular demos. The demos communicate the value and nature of your work to your teammates.
The end of a sprint is a good time to demo.
Retrospective as a scrum ceremony
After the team finishes a big release, it’s good to discuss what worked and what didn’t, what was learned and what mistakes were made. The discussion should be blameless — not in the sense that you need to anonymize faux pas, but in the sense that we all make mistakes and that every mistake is an opportunity to learn. This discussion is the retro or retrospective scrum ceremony.
Part of the scrum process is to refine the process itself and to make it fit your team. Applying critical thought and introspection to the previous sprint can only make the next sprint more effective.