Skip to main content Skip to footer
Product development life cycle

The ultimate guide to Scrum principles 9 min read
Try monday dev

In rugby, a scrum is a method of resolving disputes over which side has the ball.

The two opposing teams form up into three reinforced lines each, then push and shove for possession.

Whoever breaks first loses.

It’s a fun game. But could it have less to do with software development?

Actually…yeah. A lot less.

In the 1986 article that kickstarted the Scrum movement, “The New New Product Development Game,” Hirotaka Takeuchi and Ikujiro Nonaka urged their readers to “stop running the relay race and take up rugby.”

They chose the sport because of the way the team works together to score.

Takeuchi and Nonaka saw the old “waterfall” method of software development as absurd — like a rugby team trying to score by relaying the ball down the field one player at a time.

If you’re here, chances are you’ve heard about the Scrum framework for the Agile methodology, and want to know how you can get your own team to take up rugby.

This article will take you through the 6 principles of Scrum, and explain how you can use scrum values to smash your efficiency goals – no matter your industry.

Try monday dev

What are the 6 Scrum principles?

There’s project management principles, agile project management principles, and now Scrum principles. Trying to understand, remember, and implement them all is enough to make you pull your hair out.

What do principles have to do with successful projects anyway? Can’t you just jump into following the Scrum framework?

The Scrum principles break down why the Scrum methodology tells you to do what it does. They’re like the guiding lights that the boat (methodology) follows.

Without understanding the reason behind things like daily standups, the product backlog, and 2-week sprints, it’s easier to brush them off or follow them inconsistently.

When your Agile team embraces these 6 principles, they’re better equipped to know what parts of Scrum they can adapt to their team – and what foundational Agile steps shouldn’t be modified.

#1: Evidence, not theory

Empirical process control is the cornerstone of Scrum. Without this idea, it’s all just words.

“Empirical” means that you make each decision using hard evidence and observations.

In the old days, project managers would set out rigid plans for each project, and treat any deviation as their team’s fault.

If their plan failed when it hit reality, they’d ignore reality.

A screenshot of a Scrum board from

(Image Source)

Scrum takes the opposite tack.

Every day, the members of a Scrum team evaluate their processes, figure out what’s not working, and adjust. At the end of each sprint, the sprint review is a chance to make major changes.

Using a Scrum board, make each process clear to everybody, allowing everyone to incorporate new information into their work.’s process management template is a good starting point.

A screenshot of the process management template from

You can apply empirical process control anywhere in your life–no need for a scrum certification or an Agile coach.

#2: Organize yourself

Traditional project management methods feel a bit like being back in high school. The manager assigns tasks to everyone, and when they finish those tasks, they get assigned more.

The Scrum framework recognizes that employees are adults. They’re not just capable of managing themselves, but almost always produce better work that way.

In fact, the word “assign” does not appear in the Agile Manifesto, or any of the founding Scrum documents.

At each daily scrum meeting, members communicate among themselves. They name each product backlog item that needs to get done, and figure out how it’ll happen.

At our teams don’t even have a “leader” (called a Scrum Master.) We take the idea of self-management to heart.

For teams that use a Scrum Master, that person isn’t a drill sergeant, but a rugby coach.

Their job isn’t to give orders, but to remove obstacles standing between their team members and success.

A great Scrum Master turns their team members into unblockers for each other. That’s the way to really hit your sprint goal.

Whether you run a software development team or a bakery, your leadership will be most effective if you can get your employees invested in assigning tasks to themselves.

Good tools are the key here. A user-friendly template for team task management removes all the barriers between your team and self-organization.

A screenshot of the team task management from

Try monday dev

#3: Work together

This goes hand-in-hand with #2. To self-organize, you have to understand how to work with other people. A Scrum team isn’t the place for lone wolves or rockstar egos.

But, collaboration takes more than just communication skills. It’s also about awareness.

In a rugby scrum, if everyone’s looking side-to-side instead of forward, the other team will break right through. It’s the same on a Scrum team.

A team member’s instinct is to check with their co-workers to make sure they’re not working on the same part of the product backlog as anyone else. But it can take time to figure that out, which means lost productivity.

That’s why Scrum puts so much emphasis on tools like sprint planning, the Scrum board, sprint review, and tracking the sprint backlog. Rapid information sharing builds trust and keeps the team looking forward.

A screenshot of a sample of Project deliverables from

(Image Source)

Principle #3 is also about collaboration outside the team.

Constant communication with outside stakeholders like your client is an essential skill. Use a CRM template to make client management easy.

A screenshot of a CRM template from

And if any other teams in your company are working on a different aspect of the same long-term part of the product backlog, make sure they’re never more than a day behind on information from your team.

#4: Do the most valuable tasks first

The ability to set priorities is the bread and butter of Agile planning.

Agile software teams that follow the Scrum methodology don’t get hung up on doing everything they possibly can before they ship.

Instead, they pick the most important tasks from the product backlog and just do those.

Sounds like a no-brainer, but consider this: do you start each of your days by doing the most important things first?

Or do you get distracted by email, meetings, small talk, and putting out fires, until you realize you’ve spent your whole day being busy but not productive?

A Scrum team asks three questions to determine the priority of any task in their sprint backlog.

“What’s the value of finishing this?”

“What are the risks involved?”

“What other tasks are depending on this one?”

Use a sprint planning template to set priorities. Is your task low-value, with nothing else depending on it? Do it later.

A screenshot of the sprint planning template from

#5: Use time-blocking

Ever heard of the Pomodoro Technique? It’s easy: you work hard for 25 minutes, then take a 5-minute break. Every 2 hours, take a 30 minute break. Repeat.

That’s known as time blocking, or time-boxing, and it’s another building block of Scrum.

Spend any time talking to a Scrum veteran, and you’ll quickly notice they’re obsessed with units of time.

The most important is the sprint (a 1-4 week timeframe for completing a product increment or iteration) but the rigid 15 minute daily scrum meeting is almost as sacred.

Why is time-blocking important for Agile? Because your brain is a perfectionist – and a great procrastinator.

Left to our own devices, humans start things later, and take longer to finish.

By blocking time in a daily task manager, you can force yourself to make finished a more important state than perfect.

A screenshot of the daily task manager template from

At the same time, you’ll cut down on procrastination — and make sure the daily scrum never takes away from anyone’s deep work time.

It’s way easier to “just work for 25 minutes” than it is to “just write 1,000 words.”

#6: Break tasks down, then get them done

One word will help you understand everything about the Agile principle and scrum methodology: iterate (to do again and again).

Scrum methodology holds that finishing tasks is always better than not finishing them.

Since there’s no such thing as a perfect product, an Agile software team has two choices: ship an OK product now and improve it based on customer feedback, or ship a great product later, when the market might not want it anymore.

Iterating takes the overarching requirements of the project, and breaks them into smaller chunks, often called user stories. A good product backlog template makes this easy.

A screenshot of the product backlog template from

You can use one template to craft your overarching product backlog, and another to set each sprint goal. If part of it doesn’t work, change it during the sprint review.

Then, it’s easy to chunk down and prioritize work in the product backlog, and move top priority tasks or stories over to the sprint backlog when you’re planning your next iteration.

Breaking tasks down is another Scrum principle you can apply everywhere. Lots of people want to write a novel. How many people get started by writing the first page?


Scrum project management is a lot like rugby in one other way. It’s easy to learn, but hard to do.

What makes a good Scrum team is different for every company. But, if you apply Agile scrum methodology without looking at the evidence in front of you, it’s easy to fall into the chasm of dark scrum.

The best way to hit every sprint goal is to embrace the right tools and processes, keep your eyes open, and get to work.

Try’s daily task manager to get started – it’s a fun, simple template you can use to inject Scrum values into any situation.

Try monday dev

Get started