25% discount for PRINCE2 and ITIL until 2nd December!

Lesson 07: Daily Scrum

What’s up?

00:05.500 – Welcome back, in this lesson we’re going to talk about the daily scrums.
00:09.500 – daily scrum is a simple short daily event where developers get together talk about what they’re going to do what they’ve been doing, and plan in general. it’s for synchronization.
00:22.500 – like every other event, it’s a formal opportunity to inspect and adapt artifacts it’s also about transparency of course.
00:33.500 – it’s very important to hold the daily scrums in the same time and same place every day because that makes everything a lot simpler you know that for example each day you’re going to get together at 4:30 in your project room and talk about your plans.
00:54.500 – it’s much easier than planning it every day, text time.
00:59.500 – so like other event it’s timeboxed, and this one is timeboxed for 15 minutes.
01:07.500 – it’s always 15 minutes.
01:10.500 – what we do is that the developers get together, usually in front of their scrum board which is a physical manifestation of the sprint backlog which also contains a sprint goal. sprint goal is part of the sprint backlog.
01:27.500 – they get together and they talk about their project.
01:33.500 – now as I told you it’s only for the developers, only the developers participate in this meeting other people as usual can attend and watch them see what’s going on, for example it can be the scrum master or product owner it can be other people from other management layers in the organization people from other projects in your organization and even maybe your customer, it’s ok we keep talking about transparency so it’s fine but they may not talk, they just stand in a corner and watch you.
02:08.500 – it’s a good way of understanding what’s happening in the project, understanding the progress inside the sprint.
02:19.500 – there is something in scrum, when you’re a product owner or scrum master you can also have the accountability of a developer meaning that you can have more than one hat, you can work as a scrum master and also a developer or a product owner and also a developer.
02:41.500 – it’s not a great idea if you can you should separate those roles because their accountabilities, their responsibilities will be mixed a little bit and usually people pay more attention to the more concrete work which is development and forget about the abstract things like what we expect from the scrum master or a product owner, but in general obviously if a person who is the product owner is also a developer then that person will participate in the daily scrum as a developer not as a product owner but as a developer.
03:19.500 – now what happens here is that generally management what we say is that these are roles product owner and developer, we don’t use the word role in new scrum guide but it’s really roles, these are roles, so those are roles those are not people people play those roles. so in the scenario that I explained what happens is that the product owner doesn’t go to that meeting the same person who plays the role of the product owner goes to that meeting playing the role of a developer so we can still say that this meeting is only for the developers.
04:07.500 – however, the scrum guide doesn’t consider that concept of roles and mixes the idea of roles and accountability with people and therefor it considers the type of exception that if the product owner is also a developer, then the product owner goes to this meeting or if the scrum master is also a developer, the scrum master will also go to that meeting and participate as a developer.
04:33.500 – so just for you to know, these are the type of exam material, it’s not something that make any changes in your real work so it’s up to you.
04:47.500 – the other thing is that, one of the responsibilities or accountabilities of a scrum master is to facilitate facilitate different things, different events but not by default. they don’t do it all the time because it’s not complicated. the developers should be able to do this.
05:10.500 – so what is saying in scrum is that the scrum master facilitates as requested or required.
05:18.500 – so two different ways, if for example the developers see that well we really can’t manage our daily scrum or we are so focused on the contents that we lose track of time or something else then they can ask the scrum master to help them by facilitating this meeting or if the scrum master sees that it doesn’t matter how much they try to teach the developers they still can’t do the daily scrum properly then the scrum master may decide to go there and facilitate the meeting for a few weeks something like that, but still the facilitation is not considered participation we still consider it something that only the developers participate in.
06:09.500 – alright, so the whole daily scrum event is for synchronizing; understanding what’s happening in the project, what they’ve been doing, what they’re going to do.
06:26.500 – so in general to plan but in order to plan you need to understand your progress somehow understanding the progress in the project like this is very simple, it’s just the act of moving one card from one column to the other that.. your progress measurement is somehow implied there but it’s up to you, you can have different types of progress measurement inside the sprint for example, one thing that is not mandatory but it’s very common in the agile projects it’s to have burndown charts, something like that the one you see over there so the burndown chart shows how much of the work remains when you finish something you take the line to go down, something like that.
07:16.500 – but it’s common, it’s not a bad idea but it’s not mandatory in scrum it’s absolutely up to you.
07:29.500 – in the past there used to be three different questions that you needed to answer in daily scrum the format was that you go one by one and each developer answers those three questions what I’ve been doing since yesterday, what I’m going to do until tomorrow, and what problems I may have in the work I’m going to do tomorrow it’s a still a good idea, it’s a good practice but it is not mandatory.
08:01.500 – you know the purpose of the daily scrum and it’s up to you to see how you want to achieve that goal.
08:08.500 – so basically the purpose of this event is to inspect your progress, and when we say inspecting you always have a goal, and here what’s your goal?
08:23.500 – the sprint goal. so you will measure you will inspect your progress toward the sprint goal and the other one is to adapt your sprint backlog, and when we say adapt it’s every type of change in your sprint backlog based on your environment so basically planning is a form of adaptation when planning is not an upfront and here as you remember we don’t do all the planning in the sprint planning.
08:54.500 – we leave some of that for the duration of the sprint and one part of it is done here that’s planning and that’s done to adapt to our environment.
09:05.500 – so these are the two main purposes and when we do it properly we get something out of it.
09:13.500 – we identify the impediment the problems that we have that block our work during the sprint and when you identify the impediments as developers you try to solve them yourself.
09:29.500 – but if you cannot solve them or if it’s too difficult and time consuming for you to solve them you ask someone else who’s that person?
09:41.500 – the scrum master. you will ask the scrum master to help you by solving the impediments removing the impediments.
09:51.500 – it also the whole daily scrum helps you with your communications you know that you have to get together once a day and talk about the project because those of you who have experience of working in projects which is most of you know that this is some simple but this is something that we sometimes ignoring in our projects we don’t communicate enough we don’t have the structured way and organized way of communications.
10:20.500 – this is a very good way and it’s not only limited to agile projects, we have it in almost all agile projects the general name for it is daily standup and that’s because it’s very common for people to stand up in front of their scrum board their sprint backlog.
10:36.500 – it’s not mandatory of course, but it’s common to stand up because the whole meeting is only a 15 minutes and when you’re standing up you’re more conscious of the passing of time.
10:48.500 – so it’s the name daily stand up, but in the scrum it’s called daily scrum.
10:54.500 – so anyway it improves communications and something else that they’ve mentioned in the new scrum guide is that it promotes quick decision-making.
11:07.500 – now I’ve never been in favor of quick decision-making and… yeah decision-making is important it’s something that you have to do it properly, it’s not about doing it quickly it’ about spending enough time on decisions based on the consequences of the decisions if the consequences are limited, then you need to do it quickly but if it’s important you must spend more time and there are lots of falsies and biases that impact our decisions and we need time in order to manage them, control them and get a good result.
11:53.500 – so I don’t feel comfortable with that thing promoting quick decision-making but that’s a part of the scrum guide it’s good to know.
12:04.500 – something else here is that I mentioned the impediments the problems that people may have and they talk about it they mentioned them, they identify them during the daily scrum.
12:16.500 – what happens in most cases is that you’re together working for example, two or three developers are working in one area and they have an impediment there is one other developer who’s had a similar experience in the past and as soon as they mention the problem that developer knows the solution for that and they start helping but that’s not really helping because if you want to start talking about problems and the solutions to problems then it’s not possible to do it in 15 minutes and it’s only 15 minutes we barely have time to talk about what we’ve been doing and what we are going to do talk about progress and plan for the next day so what we do is that in this meeting we only mention the problems if there is a solution, if there is a suggestion, objection, idea we will do it after the daily scrum and the difference is that maybe not all developers need to be there when they talk about the solution to that problem maybe it’ not relevant to them maybe only those three people who have the problem and the one person who has the solution want to get together and talk about it that’s the big difference here.
13:38.500 – alright that was everything about daily scrums and in the next lesson we are going to talk about the sprint review event.

When we approach the end of the Sprint, there are two other events: Sprint Review and Sprint Retrospective. We’ll talk about them in the next two lessons.

Lesson 07: Daily Scrum

Contact your trainer to ask questions