[2025] The Complete Agile Scrum Fundamentals Masterclass

Language changes around us all the time.
It's like a living, breathing thing.
As we use and adapt words, new definitions are created to match what they mean in current times.
 

Being a traditional Waterfall project manager made it really unlikely that your project would be successfully completed.
Let alone according to the plan you laid out at the beginning.
It was more like being a weatherman doing a forecast for a specific day next year.
 

Scrum wants you to fail.
In fact, it's known for the slogan "fail fast.
                " No, I'm not joking.

Traditionally, waterfall project teams face three constraints: time, cost, and scope.
They're unable to change any of these things once their project starts.
The problem is, during the course of a project, the business environment changes around you.
 
 

Scrum is a lightweight framework that can be incredibly flexible, efficient, and powerful, but, much like a vehicle, the best body style and frame will get you nothing without a powerful engine to move you forward.
There are two key roles that exist on every Scrum team: the Product Owner and the Scrum Master.
Let's start with the Product Owner, or PO.
 

Once, I was in a position where I was given an assignment but I didn't have all the tools I needed to complete the job successfully.
I felt like I'd been set up to fail.
So when you're ready to set up your scrum team I hope you're planning to do everything you can to help them succeed.
 

I'd never go on vacation by showing up at the airport and randomly selecting a destination based on the flights they've got that day.
I don't know about you, but I'd rather choose my destination and my activities before I start my trip.
That way, I'll get exactly what I want.
 

We've talked about themes and features as groupings of work.
These are really useful constructs to help us get organized but they're still too big for a team to work on and deliver value in small timeframes.
The people we're developing for are customers or users.

At this point, you should have your themes and features broken down into user stories.
Also, you've estimated your stories using points so you know about how much work is waiting to be done.
This is your product backlog.

There are two kinds of estimation we all use every day.
There's actual estimating and relative estimating.
Actual estimating is what you use when reading a map.
 

You've done all this work preparing your themes, features and backlog.
You also know how long your sprints are, now it's time to estimate when things will be worked on.
Scrum has tools for this, as well.
 

As your team prepares for the sprint, more detailed collaboration is necessary and that's exactly what you do in your sprint planning meeting.
Full participation is critical so you'll need all your development team members, your scrum master, and product owner.
These responsibilities can't be delegated.

If you're working on a critical project it's pretty common for stakeholders to ask your team members how things are going.
This is good.
People are invested in the outcome of your project.

The scrum master, as the scrum process owner, will establish your daily scrum.
This is also commonly referred to as the daily standup meeting, or standup, for short.
In order for scrum to work, it relies on the three C's: collaboration, communication, and cadence.
 
 

In Scrum, the product owner is accountable to the team and the stakeholders.
The stakeholders want to ensure they get what they need from your project.
A key aspect to keeping the right priorities throughout the project is the ongoing refinement of the product backlog.
 

In Scrum, the team takes their sprint commitment very seriously.
They're striving each day to collaborate and get their stories to done.
Remember, in Scrum, done means usable product that meets the acceptance criteria.
 

In Scrum, we strive to deliver a working product at the end of every sprint.
But what's the point if no one knows about it? Scrum's answer to this is the demo.
As you know, the PO is accountable for accepting or rejecting what's been delivered.
 

For a scrum team, 100% of every sprint is focused on the needs of the stakeholders and the end users, but the principles behind agile say that teams need to reflect regularly on how to be more effective and adjust their behaviors accordingly.
In scrum, this principle has taken shape as the team retrospective, or retro for short.
This is the one time every sprint when the focus is not on the product, it's on the team itself.