Scrum: what is a good ceremony?

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

This methodology consists in developing our platforms in series of sprints, which are relatively short periods of time that allow us to iterate on the development of a project. These last generally last one or two weeks but at Capsens we have opted for one-week sprints in order to have a more responsive organization.

Each sprint revolves around a key meeting called a “ceremony”, which allows the developer's sprints to be structured.

The name “ceremony” is chosen deliberately because each participant has a specific role to play and the process is precise and always the same, as you will see in this article.

In this article I will try to explain to you the functioning that we have put in place to succeed in our ceremonies.

First of all, it is useful to understand who is present at this meeting and what are the roles of each.

First of all, there is The Customer. It is important that he be present at these meetings for several reasons as it allows him to:

1. Give the order of your priorities and interact with the work team,
2. Understand each development that is planned. We then avoid developing functionalities that could be useless or poorly understood,
3. Understand the various problems encountered during the last sprint and the possible delays,
4. Know the progress of the work throughout the project.

Then there is the Project manager. He is the one who prepares and leads 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 for the latter to fully understand each of the functionalities, but it is also essential that he actively participate 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 time consuming 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 Master of the project. This is a senior developer and technical project manager who reviews the work done by the developer (regardless of level). At Capsens, we strive to do the most qualitative work possible and this includes various validation processes. So any work done by a developer must be reviewed by another developer.

If the Master happens to be the developer who will implement the various functionalities, then the replacement reviewer must be present because he will be the one who will review the work done by the master.

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

At Capsens, we use Trello.

This tool allows us to easily track the progress of the work and to distribute the various tasks that are incumbent on everyone.

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 maps for the next sprints.‍
• Sprint Backlog : column in which the developer sees all the maps he must develop during the sprint.‍
• In progress : it shows the maps under development. In this column, there is always only one map per developer, as it is impossible to deal with two topics at the same time‍
• Technical Validation : column in which all the cards that have been completed by the developer and whose code must be reviewed by the Master are located. ‍
• 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 Validation : column displaying all the cards that 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 validated continuously on the project and that there will be no surprises at the end of the project. ‍
• To be deployed : This column lists the cards that have been validated and that must be deployed in production.‍
• Deployed : Here are the features that have been put into production.

There is a last column

• ‍Abnormalities : In this column are all the cards that have not passed all the validations and that need to 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 is less easy for a customer to use.

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

• 1 point: change of wording
• 2 points: minor development
• 3 points: development with a minimum of thought/research
• 5 points: a morning
• 8 points: one afternoon
• 13 points: a whole day

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

• A well-cut job is better specified
• It is more motivating for a developer to deal with small, numerous cards than large, few cards
• you 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. That is the price of quality.

After each explanation of functionality and when the Project Manager has ensured that the specification was clear to everyone, the map is estimated. When we are in person we use “physical” cards encrypted between 1 and 13. Participants give heart to their estimate and this can lead to discussions or reveal misunderstandings. Since the Covid-19 period and the democratization of teleworking, we have mainly used the site Scrum poker for our estimates.

As the developer himself has a Master role on other projects and must validate code from other developers, we cannot do 5*13 sprints but 4*13 points. That is why, at Capsens, we operate 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 a feature that is easy to implement looks like:

This meeting represents the backbone of the project and it is essential that everyone is involved and understands all the topics covered. 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, properly 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 starts the meeting by summarizing the past week with a summary of the past week with the obstacles encountered, if any, and what was achieved.

He then does a quick review from column to column, starting at the end (i.e. what needs to be deployed in production) to finally arrive at the Backlog column and start explaining the functionalities one by one.

When a ceremony is well prepared and organized, it does not need to last much longer 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 how a scrum ceremony works and what it does.

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 provide high satisfaction for the customer who is involved from the beginning to the end of the project.

‍