I heard a comment the other day from a team in our organization

As soon as release pressure increase the scrum ceremonies gets neglected

I thought to maybe have a chat with scrum master and have a session with our organization around this subject because I think this might affect more than one team. I am not sure how to approach this meeting because I know all ceremonies are important

Scrum ceremonies are important elements of the agile software delivery process. They are not just meetings for the sake of having meetings. Rather, these scrum ceremonies provide the framework for teams to get work done in a structured manner, help to set expectations, empower the team to collaborate effectively, and ultimately drive results. If they’re not managed appropriately, however, they can overwhelm calendars and drown out the value they are intended to provide.

As of writing this I dont know what "neglected" means in the context of this team but I will still have a meeting. The point is, it’s not about whether or not they are doing these things perfectly but that they are doing them at all. Each of the ceremonies has a very particular reason for its existence and continued use, so we want to target those reasons, not stick to some unnecessarily rigid definition of what’s “right” or “wrong”.

Agility requires us to adapt to changing conditions, but it starts by adopting processes that make us more likely to do the right things at the right times.

Do you have any pointers when I talk to the teams?

  • It'll be interested to see how your meeting goes. I'm wondering how that team's velocity looked during the earlier part of the release increment. Were they estimating well or were things being carried over sprint to sprint? Are they ending up under the gun in a non-sustainable way because of it? Based on what you overheard it gives me the impression they over estimated, but are being held to the projected release... Commented Feb 26, 2020 at 21:54
  • Does the team have insights in the Scrum ceremonies? The actual intention of them? Are they carried out in a way so they actually bring value? If the team doesn't see the point (anymore) - e.g. "why have a retrospective - we've done it several times, but it doesn't change anything" they are likely to ignore the and save the time. I might be able to answer better with a bit more context.
    – sonstabo
    Commented Mar 4, 2020 at 13:34

4 Answers 4


Long term success gets neglected for short term success.

A meeting like the retrospective takes time and nothing bad happens immediately if it is canceled. You need to make clear, that the Scrum ceremonies are in for the long run.

You don't do them, the team wont grow and might even collect things technical debt along the way by missing out on opportunities to better themselves. This mostly is due to the fact that communication in certain parts ceases to happen.

So point out that the time spent usually is gained back by a bigger factor, but it will take time and patience.


I may have a slightly different take than the rest of the answers.

The Scrum structure should be the tool to help reach goals faster. Effective planning, review, retro, and daily scrum should reduce the overall time spent in meetings and let teams pivot as needed to always be taking the best path forward. When the stress is high, that is when those events should pay off the most. So this begs the question: why aren't they?

The most common reason I've found is that teams are judged by their output, not their outcomes - that success is based on completion of tasks, not solving of problems and building effective products. However, don't get too anchored to this. Be genuinely curious and find out why Scrum isn't solving the problem it should.

  • To echo that thought ... "if you're paying too much attention to 'ceremonies,'" it might well mean that you have a different problem on your hands. To a certain extent, the scrum approach is idealistic: reality always gets in the way. These meetings really are not "ceremonies" at all. They are four checkpoints at which the ongoing progress and workflows are to be examined from four different perspectives. Commented Mar 10, 2020 at 15:26

Sadly this is a situation a lot of teams face in organisations that don't fully understand how Scrum works.

The key player in this is the Scrum Master.

The two main elements of the Scrum Master role are to help the team to remove impediments and to ensure that they are following Scrum. Dropping meetings due to deadlines is a good example of a situation where the Scrum Master should be standing up for the Scrum method.

The steps I would go through as a Scrum Master in this situation are:

  • Arrange the Scrum ceremonies and make it clear that you expect the team to attend
  • If there are objections then coach them on why the ceremonies are important

If after doing that the team (or somebody outside the team) insists that the ceremonies be dropped then I would report on the impact. For example, I might write a sprint report that says something like:

The team declined to hold a retrospective this sprint so that they had more time to spend on feature development. This means that we had no opportunity to address several issues that are impacting on the team's performance. As a result it is likely that by not holding the retrospective we have reduced how much we can sustainably deliver, rather than increased it.

  • And, Barnaby, if you wrote something like that, I'd be thinking in the back of my mind that "your team has a problem, and you're blaming your team for it." If there are "issues affecting the team's performance," which are impacting "what the team can sustainably deliver," then these are your problems to solve as the director of the team. If the team feels that it must knuckle-down to complete more features instead of looking back on what they just did, then the actual movement of the project isn't as you describe it anymore. You are losing management control. Commented Mar 10, 2020 at 15:30
  • 1
    The Scrum Master is not a director/manager of a team. As mentioned in my answer one of their key responsibilities is to ensure that the team is following Scrum. This is not about blaming the team. Instead, it is about making clear the impact of the chosen approach. The decision may well be to continue prioritising feature development over Scrum ceremonies, but at least now it is being done in an informed way. Commented Mar 10, 2020 at 19:15

What does "release pressure" really mean in the context of your team(s)? There are sometimes technical blockers to releases. For example, is it truly the case that every sprint delivers a potentially releasable increment? If there are additional things to be done to make a release then maybe the Definition of Done could be improved (i.e. make sure you complete those things for every sprint and not just when you want to release). Perhaps the release process itself could be improved. There are Dev-Ops tools and techniques that can help with that.

On the other hand if additional work is the source of "pressure" (i.e. the PO wants more) then maybe releasing more frequently would help smooth things out. Try to make releases a non-event as far as possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.