Scrum: what is a good ceremony?

At Capsens, we use the scrum methodology to structure our projects.

This methodology consists in developing our platforms by series of sprints which are relatively short periods allowing to iterate on the development of a project. These generally last one or two weeks, but at Capsens we have opted for one-week sprints in order to have a more reactive organization.
Each sprint revolves around a key meeting called a "ceremony" which helps structure the developer's sprints.
The name "ceremony" is chosen on purpose because each speaker has a specific role to play and the process is precise and always identical, as you will see in this article.
In this article I will try to explain to you the operation that we have put in place to make our ceremonies a success.
First of all, it is useful to understand who is present at this meeting and what their roles are.
First, there is the Customer. It is important that he is present at these meetings for several reasons because it allows him to:

1. Prioritize and interact with the work team,

2. Understand every development that is planned. We then avoid developing functionalities that could be useless or misunderstood,

3. Understand the various issues encountered during the last sprint and any delays,

4. Know the progress of the work throughout the project.

Then there is the Project Manager. He is the one who prepares and directs this meeting. This is one of the important tasks for which he is responsible.

There is, of course, the Developer. It is he who will develop all the functionalities mentioned during the meeting. It is therefore important that the latter fully understands each of the functionalities, but it is also essential that he actively participates in these meetings in order to contribute his technical expertise. In some cases, a feature may seem simple but involves a lot of technical complexities and takes up time that could otherwise be allocated. It is therefore a question of finding solutions together to satisfy the business side and the technical side.

Finally, there is the Project Master. This is a senior developer and technical manager of the project who proofreads the work that is carried out by the developer (whatever his level). At Capsens, we are committed to carrying out the most qualitative work possible and this notably involves various validation processes. Thus any work done by a developer must be proofread by another developer.

If the Master happens to be the developer who will implement the various functionalities, then the replacement proofreader must be present because he is the one who will proofread the work carried out by the master.

Now that you see who the members of this meeting are, let me explain what tools we use to identify all the features to be developed.

At Capsens, we use Trello.

This tool allows us to easily track the progress of the work and distribute the various tasks incumbent on each person.

On this board, there are 8 important columns and all the cards pass in turn in each of these columns. Here they are in order:

• Backlog
  : column in which the Project Manager prepares the cards for the next sprints.

• Sprint Backlog
  : column in which the developer sees all the cards he has to develop during the sprint.

• In progress
  : you can see the cards under development. In this column, there is always only one card per developer, because it is impossible to deal with two topics at the same time

• Technical Validation
  : column in which is all the cards that have been completed by the developer and whose code must be proofread by the Master.

• Quality Validation
  : column displaying all the cards to be tested by the Project Manager. Indeed, even after technical validation by the Master, the Project Manager must ensure that the functionality corresponds to what was specified.

• Customer Confirmation
  : column displaying all the cards which have been validated by the Project Manager and which must now be validated by the customer himself. By integrating the client into the tests, we ensure that everything has been continuously validated on the project and that there will be no surprises at the end of the project.

• To be deployed
  : This column lists the cards which have been validated and which must be deployed in production.

• Deployed
  : Here are the features that have been put into production.

• Abnormalities
  : In this column are all the cards that have not passed all the validations and which must be corrected by the developer. Fortunately, not all cards go through this column.

  Below is an example of a Trello board used for one of our projects:

Linear is a good alternative to Trello, but the tool is a bit more developer-oriented and less user-friendly for a client.

Now that you understand the stakeholders and the tool used to track jobs, you now need to understand the points system. At Capsens, a development day is worth 13 points and any feature can be worth between 1 and 13 points:

• 1 point: wording change

• 2 points: minor development

• 3 points: development with a minimum of reflection / research

• 5 points: one morning

• 8 points: one afternoon

• 13 points: a full day

It is important that a map be produced in less than a day because:

• well-cut work is better specified

• it is more motivating for a developer to deal with many small maps than with few large maps

• we can test and deploy independent pieces of code without being blocked by an element

• on the other hand, it requires a lot of specification time from the project manager. This is the price of quality.

After each functionality explanation and when the Project Manager has ensured that the specification is clear to everyone, we proceed to the estimation of the card. When we are face-to-face, we use "physical" cards numbered between 1 and 13. The participants give their estimate in heart and this can lead to discussions or reveal misunderstandings. Since the period of Covid-19 and the democratization of telework, we mainly use the Scrum-poker site for our estimates.

As the developer himself has a role of Master on other projects and must validate code from other developers, we cannot do sprints of 5*13 but of 4*13 points. This is why, at Capsens, we work with sprints of 52 points, which is the equivalent of 4 full days of work and 1 day for the ceremony itself and the rest described above.

Below is what a Trello card that includes the technical specification of an easy-to-implement feature looks like:

This meeting represents the backbone of the project and it is essential that everyone is involved and understands all the topics discussed. It is a moment of privileged exchanges between everyone and it is the responsibility of the Project Manager to ensure that this ceremony is, on the one hand, correctly prepared and, on the other hand, that everything is perfectly established at the end of the meeting.

To avoid missing a topic, the Project Manager begins the meeting by summarizing the past week with the blockages encountered, if any, and what has been accomplished.
He then does a quick column-to-column review starting at the end (i.e. what needs to be deployed in production) to finally get to the Backlog column and start explaining the features one by one.

When a ceremony is well prepared and framed, it does not need to last much more than an hour, an hour and a half. There is nothing worse than requisitioning the time of the various people present if it is not necessary.

You now understand the operation and the role of a scrum ceremony.

This meeting is the backbone of a project and allows not only to ensure that it succeeds in the most efficient way possible, but also to bring high satisfaction to the customer who is involved from the beginning to the end of the project.