The Rules vs. The Generally Accepted Practices of Scrum

In a post back in March I introduced a term on this blog that I'd been trying out in discussions and a few classes. The term was GASP and it stood for a Generally Accepted Scrum Practice. What I'm interested in right now, and I'm hoping everyone here will help with, is creating a list of all the GASPs we can think of.

But first, we need to more formally define what a GASP is. Here's my definition:

A Generally Accepted Scrum Practice (GASP) is an activity performed by many, but not necessarily all, Scrum teams. A team that does not perform the practice can still be considered to be doing Scrum. So, something like "work in short, timeboxed iterations no longer than a calendar month" is not a GASP. It is more of a Scrum rule. To be considered a GASP, the practice must be something "generally accepted" as a good idea. As a working definition of that, I've been using the idea that "every Scrum team should be aware of the practice but some teams may justifiably choose not to perform that practice, often choosing to do something similar instead."

For example, I'm going to suggest that "Conduct a sprint review meeting at the end of the sprint" is a GASP not a Scrum rule. Can a team really be considered to be doing Scrum if they forego a sprint review meeting? Yes, and I think it's becoming more common. We are seeing more teams who do as-needed mini-reviews rather than a big sprint review only at the end. For example, a team doing web development may conduct a short review with their product owner after each user story is complete and then release the new functionality to the website immediately. Is this better or worse than the single at-end sprint review? I can't say, but in some contexts I'm sure it is. And I sure wouldn't tell a team doing multiple mini-reviews that they "aren't doing Scrum."

What makes "Conduct a sprint review meeting at the end of the sprint" a GASP in this example is that the team should know about the idea of the end-of-the-sprint review. It's a good idea. Lots of teams do it. And the team in our example is free to reject it in favor of something that works better for them but they should know about it.

So, to be a GASP, a practice has to have moved beyond just a promising good new idea. It has to be something that enough Scrum teams are doing that we can call the practice "generally accepted." I'm going to suggest that "Consider user stories as your product backlog items" is a GASP. I think stories have certainly proven a worthy approach to the product backlog. Does a team have to work with user stories to do Scrum? Of course not. But I do think stories are in such common use that a team should know what they are before rejecting them in favor of something better.

In contrast to a GASP, a rule is an inviolable thing that if a team isn't doing, they aren't doing Scrum.

So: What do you think are the generally accepted practices of Scrum? What do you think are its rules? 

A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF


Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.

The discussion here is closed but join us in the Agile Mentors Community to further discuss this topic.

Go to