Lesson 01: The Big Picture

Welcome to the course! Let’s have a quick overview of Scrum in this lesson.

Note: We’ve updated this course on January 9th, 2021, to match the new version of the Scrum Guide and the PSM I exam. If you had access to this course before January 9th, your access to the old course is automatically replace with this one.

00:04.500 – Hello and welcome to the course.
00:07.000 – in this course we’re going to learn about the scrum framework, the core framework without the practices and techniques that are usually added to scrum projects.
00:17.500 – this is basically based on the PSM exam and one important thing here to note is that the whole course is based on the newest version of scrum guide 2020, and the newest version of the PSM exam which was released in January 2021.
00:37.000 – so what it means is that some of the things may not be 100% compatible with what you can see in some other resources, in some books, articles and so on.
00:48.500 – because they maybe based on previous versions of the scrum guide or on totally different perspective to scrum.
00:56.500 – ok. so Let’s get to it.
00:59.000 – let’s say we have a team of developers ok!
01:04.500 – a very common problem that we have working in projects is that every once in a while someone from the customer side comes to you asking for some changes, a new feature to.. to be added as soon as possible or changes to an existing feature and so on.
01:25.000 – which is ok, but the main problem is that there is more than one.
01:31.000 – different people come to you and each of them has their own priorities and those priorities are not compatible with each other.
01:40.000 – and sometimes even the things they ask you are not compatible with each other.
01:45.000 – so it doesn’t matter what you do, you are always being blamed by some of those people.
01:51.000 – which is really terrible, it’s very distracting.
01:53.500 – you’re there to do your professional work which is creating a piece of software.
02:01.500 – so.. there is a common solution for this problem.
02:05.500 – this is the solution that exist in different ways in all methodologies and frameworks.
02:11.500 – and it’s about creating someone or group of people whose responsible for dealing with those stakeholders.
02:22.500 – and in the scrum we have the same approach that there is a one person and we call that person the product owner.
02:29.500 – the product owner is the one whose responsible for staying (stay in) between you and everyone else who has a say in the product.
02:40.500 – anything that they want, they go to the product owner.
02:43.500 – the product owner talks to them, resolves conflicts which is a very important thing, too different people asking for too different things that are not compatible with each other, processes everything, prepares it and then brings it to you as the developers that makes everything a lot easier for you.
03:05.500 – You have only one source about the features you are going to add to the product and even the priorities.
03:15.000 – So what happens, now imagine that you are the product owner.
03:19.500 – You’re talking with many people, you’re extracting the features What do you do with them?
03:24.500 – You will certainly create a list.
03:27.000 – A to do list of all different things that you want to have in the product.
03:32.000 – And naturally as soon as you create the list you automatically start ordering the list base on their priorities, based on the importance the value they add to the product and so on.
03:45.500 – Therefore, we have this concept here the to do list for the project.
03:51.500 – Something else here happens which is again common for all projects, is that there is an objective for every project and it’s more than the some of those items.
04:10.000 – what it means is that when you have all those items the final goal of the project, the goal that you have for the product may not be implied there.
04:20.500 – Or at least if it is implied, it’s not clear enough.
04:24.500 – So it’s a good idea to define that goal and add it to the list, something there to remind us all the time that that’s the objective we have that’s why we are doing all of these things.
04:39.000 – And …this is a great practice in every type of project we always need to be aligned with that final objective in different frameworks, methodologies they have different names for it, but the concept is the same.
04:56.500 – Ok now, in scrum we have special names for these the to do list that we have is a list of items for the product and we call it the Product Backlog.
05:13.000 – And the objective for the product that’s called the Product Goal.
05:18.500 – These are the terms that we have in scrum. You know the concept and now you know the terms as well.
05:23.000 – So the product goal is part of the product backlog.
05:26.000 – the product backlog is a list of the things we want to do, an ordered list plus the product goal.
05:34.000 – Now…
05:38.000 – these lists are usually long and when you start working as a developer it may be distracting to have the whole list in front of you all the time Then that’s what many of us do as well. I’ve been doing that a long time, I have a really really long to do list and it’s even frightening when I want to look at it all the time.
06:06.500 – So what I do is that every week I pick the most important, almost urgent, things from that to do list and put them in the temporary list for the week, and during the week when I want to work, I don’t go and check my main list I only check my temporary list, the weekly list, that makes easier. that’s help me focus on the short term and also I don’t forget about the long term and because every week I go back to my main list to pick the items for the weekly list.
06:45.000 – So here for the developers in a scrum project that’s the same the product backlog is too much that’s distracting, if they want to use it in their day to day work.
06:58.000 – So they create a short term to do list for themselves.
07:03.000 – That helps. They talk to the product owner and pick a number of items normally from the top of the product backlog because those items are ordered and they put it in the short term to do list.
07:15.500 – Now there is something here that can be very helpful, with the same reasoning that we need to have a product goal, we can also have a short-term goal here, that really helps.
07:30.000 – That’s a short-term small goal that brings us closer to the main product goal, and during the week for example if it’s a week, my to do list is weekly but in the project it’s usually more than a week, but anyway, during that time period they always check their short-term objective to make sure that their interpretation of those items is correct.
07:58.000 – It helps everything to be align with our goals not as isolated separate random things, Because then you will be lost.
08:08.000 – you will be just doing, I don’t know things that don’t add enough value.
08:13.500 – Alright so these are the concepts that we have and we go on with those short-term windows of working.
08:23.000 – When we want to start a new one we check the product backlog, pick a number of items, create a shot-term list, we work on that, we will create our outputs and at the end of that window we’ll evaluate everything we will evaluate the product that we have created and the way we’ve been working, based on that and based on the feedback that we get for all those things we will make adjustments to the product backlog.
08:55.500 – We may add new items we sometimes remove items, we may make changes to the existing items, we may change the order of them everything , anything that can happen and that’s a main purpose here.
09:11.000 – So we do that and then for the next period of time again we’ll go to the product backlog, pick a number of items add them to the short-term list, create something and at the end we will evaluate everything and make adjustments to the product backlog, and we go on like that.
09:31.000 – Now in scrum these windows are called sprints.
09:38.500 – One sprint at the time , that’s how we work in scrum.
09:43.500 – In other agile systems there are They’re maybe called iterations or time boxes or other things.
09:50.500 – Alright so coming back here. We have the terms now, the term for the iteration was the sprint in the scrum and therefore the list that we have for those sprints, it’s very natural to call it the sprint backlog, and obviously the goal can be called the sprint goal, so these are the new terms we have here.
10:12.000 – The other thing that I can tell you at this time is that this sprint backlog can be expanded a little bit , normally usually it is expanded and you can create different columns in it; to do, doing , done for example if you want.
10:30.000 – and while you are doing that you can also decompose those items in to technical things that you want to do.
10:39.000 – You detail, you plan.. actually that’s a type of planning and you see our planning is continuous.
10:46.500 – We don’t add all those details to the product backlog because then the product backlog will be huge, extremely huge with too much detail and practically for something you want to do in 6 months from now there is no point in spending a lot of time and detail in that because no one knows what’s going to happened! Maybe in two weeks from now you want to remove that, you don’t want to work on it. So what’s the point?
11:12.000 – You will only plan it when it’s time to work on it.
11:16.000 – You’ll do all of these and then you start working and after a while when we are done, that thing is finished and can be part of our product.
11:28.000 – So for example; if you have a piece of software and it was version 5.2.3 now it is 5.2.3.001, something like that.
11:44.500 – It’s a new version of your product, you may not release it to the public but it’s still a version at least internally.
11:51.000 – It’s an increment of the product and in scrum it’s just called increment that’s simpler, that’s shorter.
12:02.000 – Now when you put something there, there are too many reasons here to have a very special consideration.
12:11.500 – One reason is that we want to show that increment to our customer, to our end users and so one, and receive feedback. That feedback is very helpful because it can show us the way forward, it can tell us what to do with our product backlog and what to create in the next sprints.
12:30.000 – And when we want to receive feedback based on that, we really need the increment to be done, we need everything that we put in to that increment to be really done.
12:42.000 – Without problems.
12:44.000 – Otherwise we can not rely on the feedback.
12:46.500 – that’s one reason. And the other reason is that if you don’t completely finish everything and put something there, for example it’s not properly integrated or it’s not compatible with other unites there, what I mean is that you’ve not done all the tests, including user acceptance testing, then sooner or later you will have problems with that.
13:12.500 – And when you have problems you have to go back and fix it and it’s always more difficult to fix it in future, because right now you’re working on it you know exactly what’s happening there, you can spend for example two more hours and completely finish it and then put it there, but if you don’t do it in two months from now you will run in to some mysterious problem and you may have to spend hours after hours just finding out that it was because if this and then again you have to spend a lot of time understanding how it was working and then fix it. So it’s not justifiable.
13:50.500 – It’s a lot easier if we really commit to having 100% done items when we put them in to the increment and that’s why we have a Definition of done.
14:06.000 – The definition of done is a description of what we expect from increment when we say that it’s done and obviously the items that we put in to the increment.
14:17.000 – Now being done is more than what happens with single items because it’s also about integration of each item with the other items.
14:25.500 – Alright we’re almost done with this lesson this is one of the longer lessons in this course.
14:33.000 – Going back here you remember that I told you at the end of each sprint we have an evaluation of the product and the process.
14:42.000 – When it comes to the product what we actually evaluate is the increment, the latest increment. We evaluate it with the customer with the end user and so on.
14:55.000 – Alright. So these are some of the people that working in scrum project, the developers who do the actual work and the product owner who solves millions of problems when it comes to stakeholders, and then we have few other needs that are not easily satisfied with these people, for example, we are using a framework here scrum, we have a way of working.
15:26.000 – Scrum is simple but it’s not easy there are lots of things to know and there are also a lot of techniques that you need, the developers may not know exactly how to handle a project for example the database design in an adaptive system it’s different a little bit.
15:46.000 – So they need some help.
15:48.000 – They need help from someone who knows exactly how scrum and agile in general work, what type of techniques they may need, Or the product owner for example they also need a lot of techniques.
15:59.500 – I told you that they need to order the product backlog, but how do you order the product backlog?
16:06.000 – In a certain project you may have doubts.
16:09.000 – It’s a great idea to have someone in your group, you can go to that person and ask your questions.
16:17.000 – That’s one reason, and the other reason is that we always have problems in projects.
16:22.500 – You running to problems and obviously you first try to solve it yourself, but sometimes it’s not enough.
16:29.000 – In order to solve it you have to go outside the borders of the project and deal with a lot of people and need to know how to deal with those people, not everyone is good at that.
16:39.500 – So you need someone to help you remove impediments.
16:44.000 – These two: removing impediments and helping with techniques and so on.
16:48.500 – These are the two most important reasons for having a third person in scrum project and that person is called the scrum master.
16:59.000 – Ok, So these are the people, the scrum team, I told you about a lot of things in scrum and I hope you have a big picture now.
17:10.000 – As an example I just remember this you remember I told you about.., let me go back here yeah, we have a product backlog with a product goal and sprint backlog with sprint goal right?
17:22.000 – So think about this course.
17:24.500 – The course as a whole is the product and this lesson can be like the output of one sprint.
17:31.500 – Now for the whole course we have a certain goal to learn the basics of the core scrum framework and being prepare for the PSM exam that’s product goal.
17:44.500 – Now when we come to the sprint goal in this lesson I don’t keep thinking about everything that I have to cover in this course because that’s very distracting instead of that I’m focused only on the scope of this lesson on the sprint backlog and for this lesson I also have a goal, the goal is to create a simple foundation for the next lessons, have over view of everything without going through the details and that really helps me because if it’s up to me, I will go on and on and go through a lot of details but now that I have that goal I tried to stay focused don’t go through those details let’s keep it simple for now because it will be overwhelming let’s create that foundation you have to time to do it in the next lessons.
18:41.500 – That’s how the sprint goal can help.
18:43.500 – Ok so we’re done with this lesson, in the next lesson we’re going to talk about Agile, what does it mean to be agile ?

We’ll talk about the Agility concept in the lesson.

About your trainer, Nader K. Rad

Nader K. Rad has about 24 years of experience in construction, process plant, and IT projects. He’s an expert in the history, evolution, and nature of methodologies and their practical consequences, as well as the techniques and practices that accompany them.

He has been an official reviewer of PRINCE2^® 6th edition, and PRINCE2 Agile^®, and lead author of P3.express, and NUPP. He’s also one of the 12 core team members for developing the 7th edition of the PMBOK^® Guide.

Nader is focused on helping project leaders improve their systems and get better results through coaching and training, with a focus on critical thinking and practical knowledge. He has designed many project management courses, prepared multiple eLearning courses, and written more than 40 books.

Nader’s personal website

Lesson 01: The Big Picture

About your trainer, Nader K. Rad

Contact your trainer to ask questions