Is X Allowed in Scrum?

Great Scrum Teams continuously improve their way of working. Sooner or later the team asks itself: Is this “allowed” in Scrum? Or: Is it “compatible”?

This is a decision that the Scrum Master should facilitate. But especially for new Scrum Masters this question is often a tough one.

The Scrum Guide says:

Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.


The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

In short: Adding something is okay, removing not. But out in the wild its often not that easy. The answer is often: ”It depends.” It can help the team to ask itself the following three questions.

1. Does It Reduce Our Ability to Inspect and Adapt?

The power of Scrum and Agile is the ability to respond to changing conditions quickly. This is getting more useful in contexts with high uncertainty in means of requirements or technology.

With this in mind: Does the proposed change reduce the ability to inspect and adapt? Here some examples.

Reduces ability to inspect and adapt:

  • Getting rid of
    • Sprint Planning
    • Daily Scrum
    • Sprint Review
    • Sprint Retrospective
    • Backlog Grooming

Why? Each of these events is a point to stop, check the current situation and react accordingly.

Increases ability to inspect and adapt:

  • Collaboration with the Product Owner on a daily basis
  • Invite users to user acceptance tests
  • Test Driven Development
  • Continuous Integration

Why? Each of those shortens the feedback cycle, so we have the information to act upon earlier.

2. Does It Serve the Scrum Framework or Adds It to Distraction?

The Scrum framework itself is lightweight and easy to understand. It should support the team in conducting their work as a team. By adding something to the framework, ask yourself: Will it serve the framework as a whole? Or will it add distraction? If distraction is added, the team may loose focus on what is most important: Deliver working software frequently to generate feedback. Here, too, some examples.

Does not serve the Scrum Framework, increases distraction:

  • Complicated collaboration software
  • No collocation or working remote
  • Excessive customer integration can become a disturbance to developers
  • Extending the timebox of the Daily Scrum
  • Hand-offs (even within the team, ”Mini Waterfall”)

Does serve the Scrum Framework, reduces (or does not add to) distraction:

  • Visible Definition of ”Done” beneath the task board: Clear focus on what’s ready or not.
  • Sticky notes on the door indicating time and place of the Scrum events: No asking around, no calendar software that needs to be kept up to date.
  • Poster with action items from the last retrospective beneath the coffee machine: Reminder for your commitments while you’re not focussed on the Sprint’s work.
  • Colocation: No collaboration software to tinker with.
  • Dedicated team room: Reduces organisational overhead and provides a save place.
  • Deployment checklist: A step by step guide to deployment prevents headache.

3. If We Do It, When Will We Inspect and Adapt?

However, all this is specific for the team’s context at hand. If the Scrum Team decides to add or remove something to their way or working and it doesn’t violate any given constraints of sef-organisation, it can do so. But it’s their responsibility to take over responsibility for the change, inspect the results at a given time and adapt accordingly. So the last question would be: If we do it, when will we inspect and adapt?

Related Posts

Warum vs. Wofür: 5-Why

Die 5-Why-Methode: Wo sie aufhört zu funktionieren und was stattdessen nützlich ist.

Mahara Hui 2017

Kurzbericht von der Fachtagung für Portfolioarbeit im Barcamp-Format.

1. Norddeutsches ScrumMaster-Gathering in Hannover

Kurzbericht von der Erstauflage des Events (nicht nur) für ScrumMaster.

No Product Owner, No Sprint Review?

What to Do, If There Is No Product Owner for the Sprint Review

Agile Building Games @ Spartakiade

LEGO Serious Play and LEGO Agile Games auf der Spartakiade in Berlin

Continuous Improvement Template

Support continuous improvement with the Continuous Improvement Template.

Moving the Blog

I'm moving my blog from Ghost to Jekyll.

Unread Email Count

My most reliable personal stress metric.

Scum and FrAgile

Feel free to contribute with hashtag #Scum and #FrAgile.

Organizational Culture

What is organizational culture and why you should care about it.