3 Scrum Rules We Break and Why

At The Gnar Company, we're big proponents of doing what works. We spend a lot of time using frameworks and applying methodologies – they exist for good reasons – but we're not about following rules just because someone published them on the internet. When it comes to Scrum, we've found that a bit of rule-bending goes a long way toward hitting that delivery date on (or ahead of) schedule.

Scrum is an Agile framework that enables teams to collaborate on developing, delivering, and maintaining complex products. It emphasizes iterative development, collaboration, and continuous improvement through defined roles, events, and artifacts. The Scrum Guide serves as the definitive source for Scrum guidelines and practices, and it's genuinely helpful in understanding the "why" behind the framework and for getting started with it. 

The Problem with Scrumdamentalism™

The Scrum Guide can become a sacred text for some teams and organizations. They treat every rule, ceremony, and role definition as gospel. Teams can tie themselves in knots trying to follow Process to the letter, even when it's clear it's not serving their goals.

The reality is that every project, client, and team is unique. What works for a large enterprise project might not work for a startup trying to get its MVP to market. What makes sense for a team that has been working together for years might be overkill for a team that's just getting to know one another (or vice versa). After all, the goal of Scrum is not “to do Scrum right”, it is to deliver value as efficiently as possible. You can be as flexible with the structure of your process as you like, as long as it’s done constructively and collaboratively. A good forum for evolving your process is a full team retrospective.

Coloring Outside the Lines

Maybe 'break' was a bit of a strong word, and it’s more of a ‘bending’ of Scrum to suit the current project and team's needs. As time has passed, the Scrum guide has actually become more flexible, which we’re glad to see. In any case, frameworks exist to serve teams, not the other way around. While Scrum provides an excellent foundation for Agile development, blind adherence to any set of rules can actually work against the core principles of Agile: responding to change and prioritizing working software.

Below are three “rules” we've found that thoughtful deviation from standard Scrum practices helps us deliver better results for our clients. Each represents a place where we've looked at the "official" way of doing things and asked, "But what if we did it differently?"

‍

1. Backlog Refinement Should be a Scrum Event

Here's where we actually argue for more structure than the Scrum Guide prescribes. Product Backlog Refinement is the ongoing activity of adding details, estimates, and order to backlog items. It's essential work – you can't plan effective sprints without it – but it's an ambiguous territory within the Scrum doctrine. The 2017 Scrum Guide suggested that refinement should consume no more than 10% of the development team's time per sprint; however, the 2020 version removed that language. Now, refinement feels like a footnote instead of a critical practice deserving of dedicated time and attention.

At The Gnar, we treat Backlog Refinement as a formal Scrum event, typically holding it once or twice per week, depending on the team size and sprint duration. This isn't us being process-heavy for the sake of it; it's us recognizing that consistent refinement allows us to ensure the entire team is on the same page regarding what we are building and to execute work items more efficiently when a new sprint begins.

Our refinement sessions serve multiple purposes: we examine upcoming work at regular intervals, whether that involves looking at new product backlog items, revisiting previously refined items, or reviewing designs and user flows. It provides developers with a dedicated forum to ask questions and gives the PO/SM space to work through impediments and gain clarity from stakeholders before they can derail an upcoming sprint. Seeing something once is good, but seeing something multiple times is better. Requirements evolve, understanding deepens, and edge cases surface. Regular refinement creates multiple touchpoints for this learning to happen.

As always, we stay flexible – if there's genuinely nothing to cover, we'll cancel the meeting and give folks their time back. But having it scheduled and treated as a first-class ceremony ensures that refinement actually happens consistently, rather than being squeezed in between "real" work.

‍

2. Daily Scrum Format and Cadence

The Scrum Guide is pretty specific about the Daily Scrum: it's a 15-minute event held at the same time and place every working day. The emphasis is on face-to-face communication (an Agile tenet), and most Scrum training reinforces that asynchronous stand-ups, such as those conducted through Slack, don't cut the mustard. We prefer a more pragmatic approach. We've found that Slack scrums can be incredibly effective for certain teams and situations. Our decision to go with traditional in-person dailies or an asynchronous Slack-based format depends on several factors.

Team cohesion and working style(s) are important considerations. A tight-knit team that has been collaborating for months might thrive with a quick Slack update using tools like Standup & Prosper, while a newly formed team might benefit from the face-to-face connection of traditional dailies. Given the importance of autonomous, self-organizing teams in the Scrum framework, we believe it is essential to hear what will be most useful from the folks actually doing the work.

We also examine the project lifecycle – a team in maintenance mode might not require the same level of coordination as a team beginning work on a complex new feature.

Most importantly, we incorporate our clients' needs. Some clients want that daily touchpoint and hands-on visibility. If that is the case, we're more than happy to provide it. Others trust us to get to "Done" and aren't prescriptive about our process. Budget matters, too. A 15-minute daily meeting for a large team can get expensive fast, and sometimes that cost doesn't translate to proportional value. We tailor our approach to meet their specific needs.

The beauty of Agile and Scrum is that we can always adapt; in fact, we’re expected to. We might start with daily in-person stand-ups to build team rapport, then transition to Slack-based check-ins a few times a week as the team gets into its stride. The format serves the team and the project, not the other way around.

‍

3. Project Management/Scrum Master Involvement in Product Backlog Management

According to the book, product backlog management is the Product Owner’s (PO) domain. They own the product vision, prioritize features, and make decisions about what gets built and when. Ideally, this person is on the client’s team and has a deep understanding of the business, a clear product vision, and the authority to make those decisions.

In an ideal world, every project would have a dedicated PO who lives and breathes the product. However, we rarely live in an ideal world. Clients often lack access to someone who can dedicate the necessary time for effective product ownership. Sometimes the designated PO is spread across multiple initiatives. Sometimes they have the business knowledge but may lack experience translating that into actionable backlog items.

While we always advocate for including a strong PO (and we've seen projects struggle when that role is absent or filled by the wrong person), we're also realistic about stepping in where gaps exist. Our Project Managers (PMs) and Scrum Masters (SMs) – a role that is often blended on our team – become deeply involved in product backlog management. Not because we want to (or should) own the product vision, but because we want to ensure the project succeeds.

This involvement typically looks like helping structure and refine backlog items, facilitating conversations between stakeholders to clarify requirements, weighing in on sequencing and dependencies, and ensuring that business priorities translate into actionable tickets. We might drive the backlog refinement process, but we want the PO to inform us of the best route to take.

TL;DR

Our approach isn't about throwing Scrum out the window—it's about being thoughtful and intentional about when and how we apply its principles, and evolving our process over time to meet the project's and team's needs. By staying focused on outcomes rather than process purity, we help our clients build better products and reach their goals faster. So, next time you are organizing your next project team, we challenge you to evaluate where, how, and why you might bend the rules of Scrum to better suit the needs of your Organization.