Frankly, I don't find talking about or thinking about the Scrum rules all that interesting anyway. What I find interesting is thinking of the practices of Scum. Some of practices Scumm teams use are technical and come from extreme programming. Things like test-driven development and pair programming Other practices are more focused on the product backlog. Things like user stories and product backlog grooming, sometimes called backlog refinement. Not all teams do these practices, but that's why we're going to categorize them as practices rather than rules. Having a definition of done is a great practice that many, perhaps most, Scrum teams use. It's not a rule, though. In other words, you can still be doing Sc rum even if you don't have a Here's a really minor little practice I'll mention. Don't start sprints on Mondays. When I first started doing Scrum, all the teams I worked with started sprint on Monday. We didn't even think about it. Of course, sprits start on mondays, it seemed obvious. But Monday's kind of suck for starting a sprint. No one wants to come to work on a Monday, especially if Monday has a big long planning meeting on it, All of a sudden, Monday starts to look like a great day to schedule things like dentist appointments. Because even a root canal can be better than going to a long meeting. Also, we have a lot of Monday holidays. All our presidents were born on Mondays. Monday's are just kind of bad day start a sprint. This is not a common practice. It's not well known. Is not even all that important. It's certainly not as important as the other practices I've listed here. I'd put it in the category of just a nice little optimization that could be helpful for some teams. Sprint zero is another practice that a lot of teams like. Maybe it's not a great practice or even a good one, but it is a pretty common practice, so it worth including on any list of practices. The same is true for task boards, another extremely common practice for scrum teams. When we look at all these practices, it's clear that some of these are more important than others. Some of them are so important, in fact, that I think just about any good scrumm master should be aware of him. Think about a practice like pair programming. Imagine someone walks up to you today and announces, I'm the world's greatest scrumb master. First of all, the world's greatest scrum master is probably not the type of person who would ever say something like that. But imagine someone says it, and you say, that's great. What do you think of pair programming? And the World's Greatest Scrum Master says, never heard of it. Well then, That is not The World Great Scum Master. I'm not saying The world greatest Sc rum master has to have his or her team doing pair programing. but the world's greatest scrum master better know what it is. Even if their opinion is pair programming sucks, I never recommend it to my teams. I'm fine with the World's Greatest Scrum Master having a strong opinion about any of the practices. But this is where I'd hope that that great scrumm master and I could have a conversation. And while we each enter that conversation with a stronger opinion, I'd also want each of us thinking, hey, I could be wrong, because these are the things we need to stay open-minded about. The rules are rules, and we can't fiddle around with those. Fortunately, there aren't many rules and they're easy to live with. But where agile gets interesting is with the practices. Which practices work best? and which combination of practices works best. And does that change by domain? Does it change my team size? That's where things get interesting. That where we need to be most willing to learn from one another. By having opinions, yes, but also by always admitting I could be wrong.