The Scrum Guide: FULL COURSE

Hi everyone. If you're working in agile or project management this year, you've probably heard about scrum. In fact,

more than 87% of people working in an agile team actually work in a scrum way or use part of scrum. But sometimes we don't understand where it came from and we don't actually use it the way the

scrum guide intended. So if you're wanting to learn about scrum this year, this is the perfect video for you. We're

going to go through the entire Scrum guide as written by Ken Schweber and Jeff Sutherland originally in 2010 and they've updated it. The latest version

is 2020. You can download a free version

is 2020. You can download a free version at scrumguides.org.

at scrumguides.org.

And we're going to go through this as a complete course. So, I'm going to

complete course. So, I'm going to explain. There's a few terms in the

explain. There's a few terms in the Scrum Guide. Sometimes it's just a

Scrum Guide. Sometimes it's just a little bit complex and complicated, unfortunately. There's things like

unfortunately. There's things like inspection and adaptation and empiricism and sprints and all of these terms that we may not understand. So, I'm going to

explain it in layman's terms. Let's get straight into it. This is going to be a whole bunch of fun. But now, first of all, what is in the scrum guide? We go

through the definition of scrum. Then we

look at the scrum team, who is delivering things, what they're delivering in the scrum artifacts, how we're delivering it with scrum events, and then the overall theory and values

behind scrum. So all of these things are

behind scrum. So all of these things are really, really important. And just to put it into context, initially just as a really high-level overview, the sprint

is one to four weeks and it's like a little mini project where we're delivering an increment, something that the customer can see, feel, and touch.

Now, to do that, the product owner has a list of features that they want to deliver and they prioritize the highest feature. The team breaks that down into

feature. The team breaks that down into smaller things that they can deliver within the sprint which is one to four weeks. Usually it's two weeks but it can

weeks. Usually it's two weeks but it can change and they put that into their sprint backlog. So it's just a list of

sprint backlog. So it's just a list of work. Now every day the team catches up

work. Now every day the team catches up in the daily scrum and they say hey this is what I'm working on and I need help with this and this is blocking me. Can

you help? The scrum master helps unblock and raise any issues and make sure that the team is working smoothly in a scrum way. And then the team get together and

way. And then the team get together and they demonstrate that real increment to the customer in the sprint review. Now

after that if the customer says hey that's great it looks fantastic or I've got a bit of feedback can you change this or that now that they can see it and the team also at the end of the sprint come together and talk about

their process in the sprint retrospective and they say hey this is what's working well with our process or this is what we need to change and they improve their ways of working and then they do it all again and it's a

continuous cycle of all of these things while we deliver increment after increment after increment of value. It

doesn't have to be a software project.

It could be research. It could be any other knowledge work. It could be developing a new product. But all of those things come together in the Scrum way of work. And now let's go into it in

much more detail as it's shown in the Scrum guide. So you know exactly how Ken

Scrum guide. So you know exactly how Ken Schweber and Jeff Sutherland intended Scrum to be. And first of all, what is Scrum? The Scrum definition. Scrum is a

Scrum? The Scrum definition. Scrum is a lightweight framework. So it's not

lightweight framework. So it's not heavy. It's not bogged down in

heavy. It's not bogged down in processes, but it's used for solving complex problems, delivering value through adaptive solutions. So, already

we have a few of these funny words, and it it might not make sense if you're just coming into this for the first time. First of all, complex problems.

time. First of all, complex problems. What we're looking at here is a thing called voua. We've got volatile

called voua. We've got volatile environments, uncertainty in our environment, complexity, and ambiguity.

And this actually came out of the military in the 1970s, but it applies to software projects as well because sometimes they can be uncertain and ambiguous. We can't see what the

ambiguous. We can't see what the customer is going to like uh until we actually deliver it, for example. Or we

can't see what the system how it's going to respond until we deliver it and use it. And so we deliver that increment and

it. And so we deliver that increment and then we adapt. So that is the power of scrum. By working through those complex

scrum. By working through those complex problems, the product owner prioritizes that backlog of work. The scrum team delivers that valuable increment and then the stakeholders and the team

inspect that increment and then they adapt for the next sprint and we do it over and over again just like we saw before. So that means the process is

before. So that means the process is iterative and adaptive. We're

continuously iterating, but we're also continuously changing and adapting our process and the product repeated every sprint. Scrum is intentionally simple

sprint. Scrum is intentionally simple and it's intentionally incomplete. So,

it focuses on the essential roles, events, and rules, which we're going to see, but you can use it as a container for other projects. You can fit it in to other project methodologies. Then, it's

flexible. It allows teams to integrate or drop other practices. Scrum

highlights the strengths and weaknesses in its approach to drive continuous improvement through the retrospective which we've already had a quick look at.

As we can see, we improve our process every sprint. So, we're always

every sprint. So, we're always inspecting what we do to make sure that it's to see if we need to improve or not. So, that's the definition of scrum

not. So, that's the definition of scrum just briefly. Now, who is involved in a

just briefly. Now, who is involved in a scrum team? We've got three main

scrum team? We've got three main players. the developers, the product

players. the developers, the product owner, and the scrum master. The core

unit in scrum made up of those people.

Only one scrum master, only one product owner. And that's very important. We're

owner. And that's very important. We're

going to see uh how important that is later on. And then the team of

later on. And then the team of developers. The team can be anyone who's

developers. The team can be anyone who's delivering the work, but in scrum, they are just called developers. There are no sub teams or hierarchies. It's a unified

team focused on that single product goal through the product backlog that's owned by the product owner as we saw before.

Now, here are a few more of those funny words that might seem strange at first, but I'll explain them very clearly.

Scrum teams are crossfunctional. Now,

what does that mean? That means that we bring everyone that we need to develop the product into the team. Those people

might come from many different parts of the business. maybe business people,

the business. maybe business people, maybe different systems around the business. Anyone who is needed to

business. Anyone who is needed to completely develop the product, they are crossfunctional.

And so they're also self-managing. They

decide how they perform the work. So no

one tells them how they perform the work. They see what they need to do in

work. They see what they need to do in the product backlog and then they break it down and then they decide exactly how it's broken down and how they're going to deliver those items and develop those

items. The optimal size of a team is 10 or fewer people. And we do that to stay nimble and productive. Larger teams

should be split while sharing one product goal, one product backlog, and one product owner. Now, this is important if you're taking a scrum exam.

uh if we do have multiple scrum teams uh around the same product, they should still have the same product goal and the same list of items, the same product backlog and just one product owner who

works among those various teams. Uh that's again if it's for the same product. Now the 10 people or fewer

product. Now the 10 people or fewer there's a very specific reason for this and that is because the more people we have on a team the more communication

channels we have and things start to get very very complex very very quickly because all of a sudden Billy can talk to Michelle who can talk to Michael who

can talk to an now instead of just talking one to one now we're talking one to 20 and all of those 20 people can talk to all of those other 20 people.

Trust me, it just becomes very complex.

There's actually a formula for it. I

won't go into that here, but it it increases exponentially.

So, keep the team size small if you can, and 10 or fewer is recommended in scrum itself. The team is responsible for all

itself. The team is responsible for all product related activities from development to maintenance to experimentation. Now, that's good to

experimentation. Now, that's good to know. So, the team basically owns the

know. So, the team basically owns the product. They want to keep it running.

product. They want to keep it running.

They do the maintenance and they do any experiments and they develop the new features to meet the product goal which we'll see in a second. The product goal might be just for example what are we

aiming for? Are we wanting to improve

aiming for? Are we wanting to improve sales by 50% for example then what are the features that we're delivering to meet that product goal and those

features are in the product backlog.

There you go. You're getting it already.

Okay. What else have we got here? Scrum

teams are empowered by the organization to manage their own work. They don't

have executives looking over their shoulder saying, "Oh, no, you need to do it this way. You need to do it that way." They manage their own work.

way." They manage their own work.

Working in sprints at a sustainable pace helps maintain focus and consistency.

And the whole team is accountable for delivering a valuable increment every sprint. And remember, a sprint, it's

sprint. And remember, a sprint, it's usually two weeks, but it could be one week or it could be four weeks. It's up

to the team and how they want to work because they create their own way of working. Now, developers in a scrum

working. Now, developers in a scrum team, developers are team members committed to delivering that usable increment every sprint. If it's not a software project, then they're the ones

who are creating whatever the value is they're creating. Maybe it's a new

they're creating. Maybe it's a new design, maybe it's a a new research paper, whatever that is. It doesn't have to be development and software, but it usually is. Required skills for

usually is. Required skills for developers vary depending on the domain that they're working in. But developers

are always accountable for creating the sprint plan, which is how they're going to develop the increment, ensuring quality, adjusting the plan daily to make sure that they're still going to

achieve the goal of the sprint, and that sprint is between one and four weeks.

Holding each other accountable as professionals. So making sure that

professionals. So making sure that everyone is working and doing their best. Now the product owner on the other

best. Now the product owner on the other hand is accountable for maximizing the product value created by the scrum team and mostly again they do that through the product backlog that list of

features that's going to meet the product goal. This role varies by

product goal. This role varies by organization, by team, and by individual, but it always includes the product backlog management such as defining and communicating the product

goal. Creating and clearly describing

goal. Creating and clearly describing those backlog items, that list of items, ordering those backlog items by priority, making sure we've got the

highest value first, and ensuring the backlog is transparent and understood by all. This is also very important. It's

all. This is also very important. It's

not just a secret list that they keep in their back pocket. This is something that is put everywhere. It's on the walls. It's in an open area. It's in an

walls. It's in an open area. It's in an open portal that anybody can have a look at at any time. And the product owner can show exactly why this item is the

most valuable and the next item is the next valuable. And it's transparent so

next valuable. And it's transparent so everyone can see it. The product owner might delegate tasks, but they remain accountable for the outcome for that increment that's going to meet the

product goal. The organization must

product goal. The organization must respect the product owner's decisions which are visible in the product backlog that list and the increment at the end

of the sprint that's delivered uh and it's shown at the sprint review. The

product owner is one person. It's not a committee. It's not a bunch of

committee. It's not a bunch of executives. It's just one person who

executives. It's just one person who really understands the product uh and the product's customers and they may represent many stakeholders. Others can

suggest changes but only by convincing the product owner. So in other words, the product owner has final say. They

really understand the product. They

really know what value needs to be delivered and only they in scrum can say what's going to be worked on next. Now

just as a side note uh in in the real world this can be very difficult. You

will get lots of executives trying to put their hand into things and coming up with ideas. So it can be difficult for

with ideas. So it can be difficult for an organization to trust one person as a product owner. But when you have the

product owner. But when you have the right product owner and when the organization trusts them, it is extremely powerful. It's way faster

extremely powerful. It's way faster because you haven't got lots of people and lots of committees and lots of meetings. It's just one person making

meetings. It's just one person making those decisions and making fast decisions and making really good decisions because they understand the product. So that's the power behind it

product. So that's the power behind it and that's the challenge behind it as well in the real world. Now the scrum master the scrum master is accountable

for establishing scrum within the team and within the organization in a way they are a sort of a coach but they also help remove blockers and remove

impediments and escalate issues and also bring people together if they need any extra information within the team to get the work done. So they're a pretty cool

role. They're often misunderstood. So

role. They're often misunderstood. So

let's go through the scrum master. They

promote the understanding of scrum theory and practices throughout the scrum team and the organization. And

they're responsible for the team's effectiveness by helping improve their use of scrum. But most of all, the scrum master serves the team by coaching on

self-management and cross functionality.

For example, have we got the right people in the team and or are there people outside of the team that we're relying on that's going to slow us down?

We need to bring them into the team if we can. We need our team to be crossf

we can. We need our team to be crossf functional. But self-management, are we

functional. But self-management, are we having a retrospective at the end of the sprint? Are we taking actions on the

sprint? Are we taking actions on the things that are challenging us? And are

we improving those so we're continuously improving our process? That's where the scrum master comes in handy. They

facilitate all of that and making sure that the team are is doing those things.

They help the team focus on high value increments. So they sort of they might

increments. So they sort of they might coach the product owner, make sure that the items are the highest value uh that meet the definition of done, which we'll see coming up soon. They remove blockers

within the team if they're stuck and they escalate issues if they need to.

They ensure that the scrum events are effective, productive, and within time boxes. So they have to be a really good

boxes. So they have to be a really good facilitator and make sure that everyone gets a say, everyone has a voice, but also making sure that we're running on time and getting the right things done.

The scrum master serves the product owner by supporting effective product goal definition. So they might get

goal definition. So they might get together with the product owner and facilitate a meeting and coach the product owner potentially to make sure that they have an effective backlog and

an effective product goal that the team is aiming for. Ultimately that's the product owner's role but the scrum master may help and coach in that way.

Helping the team understand clear product backlog items. So making sure that the team understands them. We might

break them down or create mockups or create wireframes so that the people can see what we're delivering. Making it

more clear supporting empirical product planning in complex environments. Now

here are a few of those funny words.

Empiricism. We're going to see this quite a lot. Basically this means real things. So we're delivering a real piece

things. So we're delivering a real piece of the system. We're not relying on just a picture or someone what someone said or even a little bit of data. It's

something real that we can see, feel, and touch. That's empirical evidence.

and touch. That's empirical evidence.

Okay? So, we're going to see that and hear about that a lot. Um, and why do we do that again? because we're working through complex environments, vauouah

environments where we need to see the real things and get feedback on them so that we can adjust and iterate forward.

Facilitating stakeholder collaboration.

Now again, if we need people from outside the team, maybe it's just a one-off or maybe we need them ongoing.

The scrum master will need to help facilitate help those teams and people come together to gather that information. The scrum master serves the

information. The scrum master serves the organization by leading, training and coaching the team on scrum adoption, advising and planning scrum

implementation. So as you can see a lot

implementation. So as you can see a lot of coaching here on scrum. The they help others embrace empirical there's that word again empirical which means real uh

delivering real things empirical approaches for complex work and removing barriers between stakeholders and scrum teams. remembering that we're bringing

people into the team if we can or if we need to. And that is our scrum team.

need to. And that is our scrum team.

Wow, pretty cool. So that's who is involved in scrum and you'll see that come up time and time again in agile as well. But what are they delivering? So

well. But what are they delivering? So

here are the scrum artifacts. What do we actually have to do in a scrum team? And

this is where we have our product backlog, which we've heard a lot about already. the sprint backlog and the

already. the sprint backlog and the increment. And we've actually heard

increment. And we've actually heard quite a bit about all of these three things. Now, we're going to go into it

things. Now, we're going to go into it in a lot of detail. And this way, again, if you're going for a scrum certification, like the professional scrum master, for example, then this is going to give it word for word from the

scrum guide, which is really, really good. So, let's see. Scrum artifacts

good. So, let's see. Scrum artifacts

represent work value and they're designed to ensure transparency. This

means again we have it on the wall.

Everyone can see our product backlog.

They can see our sprint backlog. We

review this the increment at the end of the sprint. It's transparent for

the sprint. It's transparent for everyone to see. It ensures that everyone has the same understanding for effective inspection and for us to adapt

our approaches if we need to. Each of

these artifacts includes a commitment to enhance transparency and focus. And I

really really like this. So for our product backlog which we know is our list of items, we have the commitment is our product goal. So what are we aiming for for the sprint backlog which is one

of these items that's broken down into small enough pieces to deliver in a single sprint. We have our sprint goal.

single sprint. We have our sprint goal.

So what are we aiming for in the sprint?

And lastly the increment which is the piece of value that we deliver. We have

our definition of done. Now I really like this. I won't go into that now

like this. I won't go into that now because we're going to go into it in detail later on. But just remember that definition of done is very very important. All of these commitments

important. All of these commitments reinforce empiricism. There's that word

reinforce empiricism. There's that word again. And transparency and inspection

again. And transparency and inspection and adaptation. So all of those things

and adaptation. So all of those things and they uphold the scrum values which we'll see at the very end of this course. Now the product backlog, it's a

course. Now the product backlog, it's a a product is a vehicle for delivering value to our customers. Uh it might be a system, it might be a new physical product, might be a piece of research,

might be a new design. Whatever it is, it's a vehicle. It has a clear boundary for what it is. It has known stakeholders for who's working with it.

It has defined customers and users for who gets the value. And it could be a service, could be a physical item, or it could be something else abstract. So

just know that it could be anything that you're delivering. It doesn't have to be

you're delivering. It doesn't have to be software. The product backlog is an

software. The product backlog is an emergent ordered list. Remember, highest

priority first if we can. And it's

everything that we need to improve the product and to meet the product goal.

It's the single source of work for the scrum team. Remember that we don't have

scrum team. Remember that we don't have other lists out there in the organization. We don't have executives

organization. We don't have executives coming in and saying, "Oh, you know, hey, Billy, can we can we work on on this item?" No, it has to be in the

this item?" No, it has to be in the product backlog and it has to be approved or put in there by the product owner themselves as a single person. So,

that's pretty cool. Again, it really does work when we get it right. Now, the

commitment is our product goal. The

product goal describes that future state of the product and it's our target. It's

what we're aiming for. The product

backlog evolves to deliver what we're going to uh do to achieve that product goal. The team must complete or abandon

goal. The team must complete or abandon one product goal before starting a new one. Now, this is important for any of

one. Now, this is important for any of your scrum exams. If you get a question around this, um we can't have two product goals at the same time. So we

have one and we aim for only one and if we don't want to do it anymore we abandon it. We don't just do two or

abandon it. We don't just do two or three at the same time. So always

focusing on one product goal that's very important for your exams. Now number two is the sprint backlog. This uh with the

sprint backlog it's comprised of a few things. The sprint goal. So why is what

things. The sprint goal. So why is what we're delivering valuable? It's the why behind what we're doing. Then the

product backlog items that we're going to deliver in the sprint. They have to be small enough to deliver in the sprint. If they're not small enough, we

sprint. If they're not small enough, we need to break them down further. And

then an actionable plan to deliver that increment that's put together by the developers and they can put that together in any way they want. They can

break down the work in any way they want. That's how they're going to

want. That's how they're going to deliver that work. It's created by and for the team by the developers. It

serves as a real-time visible plan for the work of the sprint and it's continuously updated throughout the sprint as more is learned. It should

contain enough detail to allow developers to inspect progress daily in our daily scrum. Now, the commitment for the sprint backlog is the sprint goal.

It's pretty straightforward, pretty easy to remember again for your exams. If you're taking a scrum exam, sprint backlog has the sprint goal, product backlog has the product goal, and the

increment has the definition of done. So

the sprint goal is the single objective for the sprint. It's a commitment by developers. It aligns and focuses

developers. It aligns and focuses focuses the team on a shared purpose. So

we're not scattering our efforts. we've

just got one focused goal and that's a great way to work. We're not

multitasking. We're not uh scattering our efforts again. So, this is really really good for focus. It provides

flexibility in how the work is done though. So, the team can decide how they

though. So, the team can decide how they actually create that value. And if the work changes, we might need to renegotiate with the product owner, but

the goal itself remains the same. Now,

lastly, we have the increment that we're developing. An increment is a concrete

developing. An increment is a concrete step towards achieving the product goal.

For example, you remember if we have a goal of 50% increased sales, then what are the features that are going to deliver that? This top feature has the

deliver that? This top feature has the most value. It's going to help increase

most value. It's going to help increase our sales by 10%. So that's going to give us a really good head start. And

when we deliver that feature, it's a concrete step towards achieving that product goal. So I hope that makes sense

product goal. So I hope that makes sense in that way. That's a nice practical way to describe it. Each increment builds on all the previous increments. So again,

the features we're delivering and each of those will increase the sales ideally a little bit. To provide value, the increment must be usable. We can see it.

We can feel it. We can touch it. We can

demonstrate it to the customer. And it's

thoroughly verified throughout the project. We're always making sure that

project. We're always making sure that we're delivering with the highest quality in mind so that it meets the customer requirements. Now, there can be

customer requirements. Now, there can be multiple increments in a sprint. So, we

could deliver more than one feature if we need to. But the sum of all of those increments is presented at the end in the sprint review to support empiricism.

Again, a few funny words here. The

sprint review is when we demonstrate the item to the customer. And empiricism is real results. All right, we're getting

real results. All right, we're getting pretty good at that now. the sprint

review. It's not a release date. So, we

can release it at any time as long as it's met our definition of done.

Definition of done is basically uh for example, how do we know when it's complete? Has it been developed, tested,

complete? Has it been developed, tested, and passed? Maybe the product owner has

and passed? Maybe the product owner has signed off and maybe we're ready for release uh or or whatever it is. It's

dependent on the team, but each team can define that definition of done. Once

it's ready, then we can release it. And

here's our definition of done. It's a

formal description of the required quality standard for an increment. So

all of those things plus anything else that you might add as your own team.

When a product backlog item meets the definition of done, an increment is created. It provides transparency by

created. It provides transparency by defining what done means for all stakeholders. But if a backlog item does

stakeholders. But if a backlog item does not meet the definition of done, then it can't be released. we can't present it in the sprint review and it's returned to the product backlog potentially for

the next sprint. We just say that they those items roll over to the next sprint. Now here's another good thing.

sprint. Now here's another good thing.

If the organization has a standard definition of done, then all scrum teams have to follow it. For example, in your company or organization, if every team

has to have uh user acceptance testing to to check it off, if it has to be signed off by a certain person in a certain department, if it has to uh be reviewed by this person or that person,

whatever that is, if it's an organizational standard, then we have to follow it. If there is no organizational

follow it. If there is no organizational standard, the scrum team can define their own definition of done. when

multiple scrum teams work on the same product like we saw before and remember if that happens we still have one product owner and one product backlog but we might have multiple teams on the

same product then they have to agree on a shared definition of done. So what

does it mean? How do we know when something is complete? That's our

definition of done. And that's all of our scrum artifacts. So who is doing scrum? What are we delivering? Now, it's

scrum? What are we delivering? Now, it's

time to get into how are we delivering it. The scrum events themselves. And

it. The scrum events themselves. And

we've seen a little bit of these already, but here's a brief overview.

Each scrum event is a formal opportunity to inspect and adapt the artifacts.

Skipping or altering events leads to missed chances for inspection and adaption. So, that's the reason why we

adaption. So, that's the reason why we do these events because we're always inspecting the process. We're always

inspecting the product and we always want to improve uh once we've done it.

So once we've looked at those things, events are designed to promote transparency and continuous improvement.

Scrum events help create regularity and reduce the need for additional meetings.

Now this is great because if we're catching up every day with the daily scrum, then we don't need to have three other meetings uh to get updates or to get information from other people. Uh so

that's one of the good things that can happen when we hold these events regularly. Holding them at the same time

regularly. Holding them at the same time and place also helps reduce complexity.

Now the first one is the sprint which we remember is one to four weeks depending on the team depending on the product.

It's like a short project offering clear time frames and focus and at the end we deliver that increment. So it really is like a a little mini project. The sprint

is the container for all of the other scrum events that we'll go through.

Shorter sprints can reduce complexity, can reduce risk, and can also increase our learning opportunities as we're having retrospectives more more frequently. We can also use things like

frequently. We can also use things like forecasting tools. You might come across

forecasting tools. You might come across burndown charts or burnup charts or cumulative flow diagrams. many different ways to measure your team and that can

help but it doesn't replace that magic word empiricism which is the real results real increments real things of value that we can see feel and touch in

complex environments only past outcomes can guide future decisions so we want real results so we can adapt a sprint can be cancelled only by the product

owner now this is very handy for your scrum exams the product owner. If you

get a question around this and we're canceling a sprint, only the product owner can do it. And only if the sprint goal becomes obsolete, the sprint if the

sprint goal still stands, then we continue on and we want to aim to achieve that sprint goal and we the team decides how to do that. If you remember,

sprints are the heartbeat of scrum where ideas are transformed into value. They

are fixed length events a maximum of one month that start immediately after the previous sprint ends. So we're

continuously uh iterating forward.

During the sprint, the sprint goal must remain stable. Quality must not

remain stable. Quality must not decrease. The product backlog can be

decrease. The product backlog can be refined into smaller items with more information on them. The scope can be clarified or renegotiated with the

product owner as more is learned. But

again we're aiming for that goal. The

goal must not change but the scope and how we get there can change. Now one

extra thing and the product backlog as you know is our list but there is an activity that we'll perform. It's not

really event an event in itself but it's an ongoing activity. So just keep this in mind. It's product backlog

in mind. It's product backlog refinement. This is where the team comes

refinement. This is where the team comes together and they break down and they define those product backlog items more precisely. Now it can happen any time.

precisely. Now it can happen any time.

It happens throughout the sprint. Uh

there is no set time. It doesn't have to happen on a particular day and it doesn't have to happen within a particular time frame. The team adds details such as the description, the order and the size of the product

backlog item. So we're giving it more

backlog item. So we're giving it more information. Developers are the ones

information. Developers are the ones responsible for sizing the items. So, how long will it take to deliver? How

complex is it? What is the size? Is it

small? Is it medium, large, extra large?

And there are various sizing methods.

Those aren't described in the scrum guide. You might use the Fibonacci

guide. You might use the Fibonacci sequence or you might use t-shirt sizing small medium large extra large, just as some examples. The

product owner supports by clarifying tradeoffs. So if we need to trade off

tradeoffs. So if we need to trade off any items, if we need to take something out or add something in, the product owner can help. And they help developers understand the priority. So if we're

going for that 50% sales target, that is our highest priority. That's what we're trying to meet with this particular feature. That's our example. Now, sprint

feature. That's our example. Now, sprint

planning for your exam is time boxed to 8 hours. So, maximum of eight hours for

8 hours. So, maximum of eight hours for a one- month sprint. That can be a long time. In the real world, typically it's

time. In the real world, typically it's around an hour or less. Um, shorter

sprints equals shorter planning. So, if

we've got a one week sprint, we can have shorter planning. If we've got two week

shorter planning. If we've got two week sprint, we can have shorter planning.

Sprint planning starts the sprint by creating a collaborative plan for the work ahead. So, we're planning the

work ahead. So, we're planning the upcoming work. the entire scrum team

upcoming work. the entire scrum team participates and others can be invited if they have information that we need.

So, we're we're planning together, but we have um Billy over here has some information that we need uh in order to make sure that we're delivering the right thing. So, we invite Billy over to

right thing. So, we invite Billy over to our sprint planning to give that information. Now, if you think about it,

information. Now, if you think about it, we could get that information from Billy during backlog refinement as well. So,

something to think about. The product

owner ensures that the team is ready to discuss high priority product backlog items and how they support the product goal. So I I feel like I've said this

goal. So I I feel like I've said this maybe 20 times in 20 different ways. So

really it it it comes down to just a few core things as you're probably noticing, but we say it and we sort of go over it in many many different ways in the Scrum guide. So pretty interesting to see

guide. So pretty interesting to see items that can be completed within one sprint are considered ready. So that's

important for your exam as well.

Remember, if it's if it can't be completed within a sprint, then it's not ready for sprint planning. It has to be small enough to complete within a

sprint. Sprint planning covers three

sprint. Sprint planning covers three main topics. Why is the sprint valuable?

main topics. Why is the sprint valuable?

What can be done in the sprint? And how

will the chosen work get done? Now for

why is a sprint valuable? The team

collaboratively defines the sprint goal.

Why are we doing what we're doing? It

explains the sprint's value to stakeholders. The product owner gives

stakeholders. The product owner gives guidance on this and also how value could be increased. The sprint goal must be finalized during sprint planning and

it's usually pretty easy to do. It's

just uh what is the outcome and why is it valuable for our team and we make sure we do that before the end of sprint planning. Now we also plan what work can

planning. Now we also plan what work can be done in the sprint. developers and

the product owner select the product backlog items to include. Remember, it

has to be small enough to complete in a sprint. Otherwise, it's not ready for

sprint. Otherwise, it's not ready for the sprint uh for sprint planning. Items

may be refined during planning to build understanding and confidence. So, we can refine them further during sprint planning if we need to. But for me personally, I prefer to do backlog

refinement before sprint planning and to make sure that everything is nice and ready. Make sure we have a good product

ready. Make sure we have a good product backlog and it's and it's properly refined so we're ready to go. Accurate

forecasting depends on past performance, current capacity and the definition of done. Now again a lot of words here. Now

done. Now again a lot of words here. Now

what does that mean in the real world?

For example, if we have delivered uh say 20 user story points or 20 user story cards or 20 items in the last sprint,

then what we're going to do is place 20 items in the next sprint. We want the pace to be sustainable. So, we're

matching our current capacity to our past performance. That's what that

past performance. That's what that means. How will the chosen work get

means. How will the chosen work get done? Developers plan how to turn the

done? Developers plan how to turn the selected backlog items into a usable increment. Which means they take that

increment. Which means they take that feature and they break it down into something that makes sense to them that they can work on and deliver at the end.

This often involves breaking down those items into dailyized tasks. There you

go. And developers have full autonomy over how they do the work. No one tells them how to do it. They're the ones who decide. So we've done our sprint

decide. So we've done our sprint planning. We've got all of our work

planning. We've got all of our work planned and now we're working as hard as we can. Every day we have the daily

we can. Every day we have the daily scrum which is our next event. It's a

15minute daily event for developers or anyone working on the product to inspect the progress towards the sprint goal. So

in other words, how are we going? Uh do

we need any help? Uh is there information that we don't have that we do need? We want to adapt the sprint

do need? We want to adapt the sprint backlog and update the plan for the next 24 hours when we'll have another daily scrum and catch up again. It's held at the same time and place each working day

to reduce complexity so we know when it's going to happen. It's nice and straightforward. If the product owner or

straightforward. If the product owner or scrum master are working on sprint backlog items, then they can participate in the daily scrum. Otherwise, it's only

for people doing the work. It's only for developers. But uh if anyone else is

developers. But uh if anyone else is working on an item then they can participate as developers. So I hope that makes sense. But what that means is we don't typically want other people

especially like executives or or other stakeholders who are not doing the work.

We don't really want them involved. This

is more just for the people who are who are actually getting things done at this time. Developers also can choose their

time. Developers also can choose their own structure or techniques as long as they stay focused on the sprint goal progress and that it results in an actionable plan for the next day. So

what am I going to be doing uh for tomorrow by the time we catch up again?

Now there are a few benefits of the daily scrum. It improves communication.

daily scrum. It improves communication.

It helps identify impediments or blockers or things blocking our work. It

enables quick decision-m because we're all there and we can get fast answers if we need to. It reduces the need for any additional meetings and developers can

always replan any time during the day.

The daily scrum isn't the only time for updates. So just remember that uh we can

updates. So just remember that uh we can catch up separately if we need to. But

having that daily scrum should help. Now

once we've done that and we've delivered a little increment of value, we can review that with our customer. That's

our sprint review. The purpose of the sprint review is to inspect the sprint's outcome. And remember, it has to be

outcome. And remember, it has to be empiric. It's empiricism. It's real.

empiric. It's empiricism. It's real.

It's a real item that we can see, feel, and touch. Decide what to do next based

and touch. Decide what to do next based on progress and changes. So, does the customer like it? Do they need feedback?

Do they need changes? Then we can adapt.

The scrum team presents that work to key stakeholders. Together, the scrum team

stakeholders. Together, the scrum team and the stakeholders review what they accomplished. They discuss the progress

accomplished. They discuss the progress towards that sprint goal. So, how are we going? Is this going to help us meet our

going? Is this going to help us meet our sales target of 50% or whatever that looks like for our product goal? We can

identify changes in the environment and collaborate on next steps. The product

backlog can be updated now because maybe we delivered something and it didn't have the result that we needed. So, we

might take a different item from the product backlog and say, "Hey, that needs to come next because um that's now that has the most value based on what we've seen in this increment, based on

these insights, based on these opportunities, which is pretty cool.

Really nice way to work, an empiric way to work. Now, the sprint review is a

to work. Now, the sprint review is a working session. It's not just a

working session. It's not just a presentation. Active collaboration is

presentation. Active collaboration is encouraged. The sprint review is the

encouraged. The sprint review is the second to last event in sprint. The last

one is our retrospective and it's time boxed to 4 hours. Now remember this for your scrum exams, 4 hours for a one- month sprint. So just to reiterate,

month sprint. So just to reiterate, we've got 8 hours for sprint planning, 15 minutes for the daily scrum, and now

we've got 4 hours for our sprint review.

That's the maximum. Typically, it's much less in the real world. Uh it's shorter if the sprint is shorter. And now just a little anecdote from the real world. I

remember working with a team where for their sprint review, they actually didn't have an increment that they could show to the customer. So they

pre-recorded a presentation for the customer. Now, that actually ended up

customer. Now, that actually ended up being terrible because while the presentation looked good, the item actually wasn't real. It they they weren't showing how it really worked.

And when they released it, it didn't operate the way that they showed it. So

that's why we need empiric evidence. And

actually, just as a side note, Apple themselves, so Apple computers have done this as well where they've uh created a showcase and it's pre-recorded and it's pre-esigned, but they're not actually

demonstrating the real increment or the real result. In fact, they haven't even

real result. In fact, they haven't even finished developing it yet. So this was one of their Siri updates for for AI.

And so they just they had not even finished it. And when the time came for

finished it. And when the time came for it to release, it wasn't ready. and now

two years later it's still not ready.

Not a great look. Uh and it happens in the real world all the time. So always

always try and go for that real increment if you can. Now the last event is our sprint retrospective. The

retrospective helps us plan improvements in quality and effectiveness. The scrum

team inspects how the last sprint went in terms of individuals and interactions, processes and tools, and our definition of done. And if we need

to improve, then we can change and improve. The team identifies assumptions

improve. The team identifies assumptions that led them off track, explores the root cause and their origins, reviews what went well, what problems occurred, and how they were handled. And then we

take the most impactful improvements that we can and we implement them as quickly as possible. These changes could be added to the sprint backlog if we need to or they might just be done if we

need to change our way of working. And

the scrum master can help there. The

sprint retrospective is the final event in the sprint. It's time boxed to 3 hours for a one-mon sprint or shorter for shorter sprints. So now we have 8

hours for sprint planning, 15 minutes for the daily scrum, uh 4 hours for the sprint review, and 3 hours for the sprint retrospective. So just keep that

sprint retrospective. So just keep that in mind. Uh especially if you're going

in mind. Uh especially if you're going through the exam in the real world, it's up to you and the team, but for your scrum exam, you'll need to know those particular time frames. So and it just

goes 8, four, and then three as it goes along. So it gets less as we go along.

along. So it gets less as we go along.

Nice and easy to remember. and also nice and easy to remember. We've gone through the definition, the team, the artifacts, the events, and now it's time to look at

the scrum theory and values that we have as we're working in a scrum team.

Starting with scrum theory, which focuses on being transparent, as we've seen a lot of, by the way, inspection and adaptation, which we've also seen a

lot of. So all of the things that we do

lot of. So all of the things that we do support this scrum theory. Now scrum is based on empiricism and lean thinking.

Remember what empiricism is. You can

tell me by this stage. You'll be

teaching me scrum at the end of this.

Remember it's the real increment, real experience and real observation. Lean

thinking on the other hand is eliminating waste in the process and only focusing on what is essential. Now

there are whole courses on lean and I've written a few books on lean myself. It's

a wonderful way to work. Basically again

it's removing anything that doesn't add value to our customer. Uh so anything that's nonvalue ad we want to get rid of if we can to run more smoothly and more

leanly. Uh it also uses iterative

leanly. Uh it also uses iterative incremental approaches to improve predictability and manage risk. And

we've seen that we're continually iterating and we're delivering small increments of value. So that's our iterative incremental approaches. Scrum

teams are crossunctional with all the skills needed to complete the work or the ability to acquire them and we've seen that as well as we worked with our

scrum team at the beginning here. Now

transparency work and processes must be visible to everyone. people doing the work and people receiving the work so that we can adapt and inspect it and

adapt. Scrum relies on the transparency

adapt. Scrum relies on the transparency of these artifacts, the product backlog, sprint backlog, and the increment for informed decision making. Low

transparency can result in poor decisions because we don't have all the information we need to make the decision. It reduces value and it

decision. It reduces value and it increases risk. Transparency enables

increases risk. Transparency enables effective inspection. Without it,

effective inspection. Without it, inspection is misleading and wasteful.

Like that showcase that we were talking about before, the pre-recorded showcase, it was a waste. It wasn't real. And then

when we release to the customer, it wasn't a good outcome. So, we want it to be transparent. We want it to be real,

be transparent. We want it to be real, empiric. Now, inspection. Scrum

empiric. Now, inspection. Scrum

artifacts and the and progress towards goals must be regularly and thoroughly inspected to identify issues or deviations. So, we're always looking at

deviations. So, we're always looking at what we've done. Scrum uses five events and we've been through those to create a regular cadence for inspection.

Remember, it's the sprint, sprint planning, daily scrum, sprint review, and the sprint retrospective.

Inspection supports adaptation. So, we

inspect and then we update our approach, update the product, we adapt to the situation. Scrum events are intended to

situation. Scrum events are intended to drive change and to drive continuous improvement. Now lastly, adaptation. If

improvement. Now lastly, adaptation. If

a process or product falls outside acceptable limits, we should adjust quickly to avoid further issues. Timely

adaptation is essential to minimize deviation. Now, what that means is if we

deviation. Now, what that means is if we see that we're going off track and we adjust here, then we're going back on track. But if we wait then it's going to

track. But if we wait then it's going to go further and further off track. So and

sometimes that could be exponentially off track. So we want to adjust quickly

off track. So we want to adjust quickly if we can. Adaptation is harder when teams are not empowered. Remember if we have those uh executives looking over

our shoulder saying no no you need to do it this way or you need to deliver this item. I've got a friend who who owns

item. I've got a friend who who owns this business and we need to help we need to add a feature that helps that person. you know, stuff like that. Just

person. you know, stuff like that. Just

crazy stuff that doesn't really help our product goal. If we're not empowered,

product goal. If we're not empowered, it's going to be hard. So, make sure that the team is empowered and self-managing. We give them the power to

self-managing. We give them the power to do it. Scrum teams are expected to adapt

do it. Scrum teams are expected to adapt immediately based on what they learn through inspection. That's our scrum

through inspection. That's our scrum theory. But what are the values that we

theory. But what are the values that we need in a scrum team? We have commitment to the team goals and supporting the team. focus on the sprint work and

team. focus on the sprint work and making progress, openness about any challenges that we're facing, and the courage to face difficult problems and do what's right. Now, this is actually a

really good one to do what's right. For

example, do we do just a quick and hacky fix uh in our system or do we take a little bit of extra time and make sure that it's done right so that our future

selves makes it easier for our future selves or it makes it easier for the customer in the future. We want to do what's right if we can and we have respect for each team member's

capabilities and the independence of each team member. These are the values that guide the team's work, behavior, and decisions. Scrum practices should

and decisions. Scrum practices should reinforce these values. And as the teams embody the values, the scrum pillars of transparency, inspection, and adaptation

come to life and help build that trust.

So commitment, focus, openness, respect, and courage. Really wonderful scrum

and courage. Really wonderful scrum values and really wonderful scrum guide from Ken Schwabber and Jeff Sutherland.

Thank you so much to those guys who have created this wonderful way of work again that 87% of people will be using in agile teams around the world that you've

probably touched on in some way yourself in your own project team. Now, I hope this has helped you. This is the complete Scrum guide explained with a little bit of extra context and some real world stories. Oh, I've had a whole

bunch of fun and I hope you've had some fun, too. Now, go out there and deliver

fun, too. Now, go out there and deliver some amazing value. use it in your teams and continue to do great things. I'll

see you in the next video. Bye for now.