A Quick Guide to Successful Scrum Ceremonies

When working in an Agile framework, all meetings should have a clear purpose; we want to eliminate waste. Scrum ceremonies are pre-set meetings in an Agile environment. They’re well defined, have does and don’ts, and most importantly have a clear purpose. Scrum ceremonies are the backbone of a Scrum framework, they promote and encourage the key Agile principles that help teams become efficient and perform at the top of their game.

Here is a guide on what these ceremonies are, why they are used in Agile, and some top tips on running them successfully.

What it is: Stand-up is a tech team’s bread and butter. They are used in both Scrum, and Kanban frameworks. At the start of each day, the team meets to hear updates, blockers and impedances from the rest of the team — it normally signals the start of a working day. They are often led by the Scrum Master or BA, and should last at longest 15 minutes, if they are any longer either too many people are in the stand-up, or each person needs to give shorter updates.

Stand-ups are usually led by a board and all work must be recorded as a ticket on the board. They can either have the emphasis on the people, or on the work. To focus on the work, each ticket from the board is chosen and the owner gives their update on that ticket. To focus on the people, each person is asked to give their update in turn. Each have their own pros and cons.

Why they are used: They help promote transparency — one of three key pillars of Scrum. All work is accounted for as a ticket, so everyone is aware of the progress. This helps to highlight impedances and blockers to get them sorted quickly.

They help to unite the vision of the team, and to make sure everyone is working towards the same goal.

Top tips: Make your update concise, make sure you’re not just listing all your meetings, or your precise day. The team just needs to hear what your update on your ticket is, how it’s progressed and if you have any blockers. Also be sure to only talk about the current project, the team doesn’t need to know about other work external to the project.

Stand-ups are not optional. Because they are quick, sometimes team members can feel as though they can be missed. This is not the case, as often there are vital updates during them — if an update needs repeating, this is wasteful, and duplicates work. If a team member is not able to make the stand-up, they should send their update to the team via a messaging app or a proxy (even if they don’t have an update!).

What it is: A Retrospective (or Retro) is another classic scrum ceremony. Although they are usually held at the end of sprints, so lend themselves to more of a Scrum framework, sometimes Kanban teams like to adopt this ceremony too.

A Retro is a chance for a team to reflect on the previous sprint. What went well, what didn’t. It gives the team a chance to bond, and to discuss any problems they’re having. This can be anything from ways of working, external teams, to internal bugs.

The Retro is run using a board, where team members can place post-it notes or tickets with their thoughts attached. The board can be split up many ways. One of the most common is to ask the team what went well, what went bad, and what went ok. The Delivery Manager or Scrum Master will then go through each ticket, and if there is a problem, an action with an owner should be decided.

Why they are used: They again help promote transparency. The team can bond over ideas and thoughts about the previous sprint.

They emphasise iteration and constant improvement. They help the team tune their ways of working. This again is a key agile principle.

Top tips: If the Retro is virtual, it can be quite good to have people receive the board early to add tickets throughout the sprint — this can produce really realistic tickets. If this doesn’t make sense for your project, then sharing the board at least an hour before the session would be helpful.

Sometimes it helps to mix up how the Retro is done. You don’t have to stick with one way of doing it for the whole project; Sad/Glad/Mad, Stop/Start/Continue and Sailboat are just a few ways to run the Retro.

If the team is struggling to come up with any feedback, icebreakers before the start of the Retro may get the team in the mood to dig a little deeper.

What it is: A Show and Tell (aka a Sprint Review) is an opportunity to show stakeholders what the team has produced. They describe the main objective of the sprint, highlight the key achievements by the team, contain demonstrations of the work produced by the team, and describe the goals of the next sprint.

Why they are used: They’re a really good way to get the team members to feel connected to their work, and remember what is at stake. The team get to share their success with each other and externally.

Again, they help promote transparency — but this time externally.

Top tips: The Show and Tell deck is a good base for the sprint report (if you are required to make one).

The content shown needs to be clear and have value. It might be a good idea for the team to practice their Show and Tell beforehand to gain feedback before presenting externally to stakeholders.

What it is: Sprint Planning is normally the event that kicks off the sprint. Tickets for the upcoming sprint are brought into play from the backlog. Each sprint should have an objective, the tickets brought into the sprint should reinforce that objective. Before the tickets are brought into sprint they need to be sized, this can be done either in Sprint Planning, or in a separate Backlog Refinement session. The size of the sprint should line up with the team’s current velocity.

Why they are used: They are necessary for ensuring that the objective of the next sprint is clear, and to create work for the team.

Top tips: It is the role of the Scrum Master or Delivery Manager to protect the team from promising either too much or too little in the sprint. It’s really important to get the correct amount of work into the sprint.

In a Scrum framework, tickets should not be brought into the sprint after it has started, as this can disrupt the velocity of the sprint. This means all tickets that need to be completed should be brought into the sprint at sprint planning.

What it is: Backlog refinement isn’t actually a Scrum ceremony, it’s referred to as a GASP — generally accepted Scrum practice. It’s a session used by many Scrum teams, but not all. I’ve included it here as it supports the Sprint Planning ceremony if tickets are not sized during Sprint Planning. If tickets are sized during the Sprint Planning, then a smaller Backlog Refinement session may still take place — instead of the whole team attending, just the Scrum Master, Product Owner, Tech Lead and QA Lead may attend.

In a Backlog Refinement session, the team meets to ‘groom’ the backlog of tickets. The team reviews the acceptance criteria on tickets, and decides whether there is sufficient information for the ticket to be worked on (and whether the ticket is still required).

The tickets are then sized. The sizing guide is usually decided in the kick-off Ways of Working meeting at the start of the project — there are a few different ways to do it. T-shirt sizing (using a XS, S, M, L, XL system), or Fibonacci (1, 2, 3, 5, 8, 13) are both common ways. It’s also accepted to use the number of days required to complete a ticket, but I find this adds restraints to the ticket and doesn’t allow for mistakes. I find it much more helpful for the size be dimensionless.

Why they are used: Backlog Refinement sessions prepare the backlog for Sprint Planning. They’re useful for the team to see what work is on the horizon, to keep that clear vision of the project.

Top tips: The team ways of working should say what should be included in the sizing, for example: does it include the size of testing? Sometimes a ticket can take a really long time to develop but really quick to test and visa versa. If the test work is involved in the ticket, then the QA also needs to be involved in sizing.

Ideally, each team member estimating should not see what the rest of the team have estimated. This can cause the sizing to be biased. Often team members have different ideas of what could be involved in the ticket, and you lose that range of ideas if the team are swayed by the sizing of others. Techniques like planning poker can avoid this issue.

By Sarah Littlejohn

Related posts:

Below are 25 frequently asked Pyspark interview questions :. “25 Pyspark interview questions for Bigdata Engineers” is published by Singaram Palaniappan.

Aside from the practical applications of Gaussian processes (“GPs”) and Gaussian process regression (“GPR”) in statistics and machine learning, the theory underlying GPs offers considerable…

There has been much wrangling over the pros and cons of moving forward with impeachment proceedings against President Trump (two words that many a conscientious citizen still finds hard to…