Scrum

00:02

Hello and welcome to Module three. The flavors of agile.

00:07

In this video, we're going to cover Lesson 3.1 scrum.

00:12

In future videos, you'll see Lesson 3.2 lean 3.3 XP,

00:20

3.4 d sdm

00:23

and 3.5 Kon Bon

00:29

Lesson 3.1 scrum. In this lesson, we're going to cover what scrum is and also talk about sprint planning. Sprint planning is not totally unique to scrum,

00:42

but it is the method of agile that made sprint planning pretty popular. So we talk as we get through the different flavors we talked. We will talk about

00:52

the fact that you can intermingle all of these different items, so there's a lot of overlap within the different flavors of agile.

01:03

So what is Scrum? Scrum is taken from the rugby the sport and it's basically a method or a flavor of agile with five overriding principles.

01:17

The 1st 1 is the focused on the team, so in scrum, there is a heavy level of interaction between different team members.

01:25

Whenever possible, you want to try and put team members in the same physical area so they work together every day. They see each other every day. That close collaboration is a very important facet of scrum.

01:38

Scrum also talks about or focuses on what's known as the minimum viable product a minimum viable product in the case of software, which is what agile is typically used for,

01:51

it talks about what is the smallest number of features or the basic core of our application that we have toe have in order to put something to market and actually generate income from it. So if you think in terms of, let's say Amazon, for example,

02:07

the minimum viable product for Amazon would probably include

02:13

some of the basic features like being being ableto have your own customer account

02:17

being able to shop for products, place him in a shopping cart, calculate shipping order room and have them show up to your house. So those were the minimum viable products for an Amazon type application.

02:30

All of the features that you see today when you've got different suggestions and you can shop through a charity window

02:38

on donate some money to charity. Of course, all of the different electronic products and fire TV and all of these other things are all additional features. But they were not required to bring Amazon live. So that's an example of a minimum viable product.

02:58

In addition to the minimum viable product you also have what's known as a product backlog on a product backlog or a feature backlog is basically a list of things that talk or that we want to do a list of features, a list of items that we would like to see

03:15

in our application and every time that we have a sprint, which we'll get into more detail in a later slide every time we have a sprint. Whatever backlog items did not get complete in that sprint go back into the overall backlog, um,

03:34

of of the entire project. So

03:37

using product backlog is just a different way of categorizing the work. And if you've taken my Enterprise project management class, for example, we talked a lot about dependencies and how different items and featured relate to each other.

03:53

You'll notice throughout the rest of this course when we're talking about agile, we don't really focus on

03:59

the dependencies between different things. We assume with that close team collaboration that the how how things relate how they get built is understood by the developers. It's not something that the project manager has to explicitly state in the project plan

04:17

Scrum is also

04:19

very commonly known with using sprints and sprints are short, usually two weeks. Although I have seen him go is long as 1/4. But I don't recommend that link the time, but usually a couple weeks, maybe a month. And these sprints are aware we we like the name implies we sprint. We have two weeks

04:40

to try and get as much work done as possible.

04:43

So if you remember from the Iron Triangle, what we're talking about here is something that has a fixed aeration those sprints,

04:50

we lock in the duration.

04:53

So we know that because the iron triangle good, fast, cheap picked to what the what is the variable is the amount of effort that we're gonna put in, although we want always try to maximize effort, but also the feature. So the product backlog

05:09

and this there also another thing called a sprint backlog, which is what you add during the sprint planning phase.

05:14

Um,

05:15

we don't always get everything that we think we can build in that time frame, and that's okay. What we're trying to do is estimate and what we think we can get done.

05:27

Do the sprint and if the items aren't complete, then they just go back into the backlog and we move on to the next sprint. So the nice thing about that is even if you're relatively bad at forecasting

05:41

the way that scrum and and Sprint planning works, that allows you to be for lack of better expression, consistently bad it at

05:47

estimating so it's sort of a way for the project manager in the project team self correct between what we think we can accomplish and what we actually are able to accomplish.

06:00

So the first step in scrum is actually to do up the Sprint planning. So course when you're not, when you don't have a minimum viable product yet, that's the major focus of all. Your planning is getting to that minimum viable product, but once the minimum viable product is done, it's in production. Now we're going to go through our splint sprint planning session

06:19

and talk about

06:21

what are the goals for that sprint. So we're gonna look at our listing backlog of all the cool things we want to do What are we going to do in this sprint? That's part of the sprint planning. Then we assign resource is to those items the general rule. We try to make it limited toe one person per item. So that way,

06:41

if you're not able to do that, then you haven't probably broken down the work enough. But we do want to always try to get one person

06:47

assigned to each sprint item on that is the Who.

06:53

Then the person who has been assigned the task is going to figure out the technique or the how that they want to go about getting that

07:01

item accomplished. Then you're also going to estimate the sprint itself, which means, as we're talking, you say, I want you to build X, Y and Z, and I think to myself, OK, on a scale of 1 to 10 or 12 20 we're not talking about ours. Were just talking about effort in general.

07:17

How much effort do I think that this will take? And this is where that self correcting thing comes from, because if every sprint we estimate and I'm a very cautious estimator and I think that's gonna be a 10 and that's gonna be really hard, but I'm able to get lots and lots of 10 items done.

07:36

Then the project manager will know in future sprints that he can actually ADM or things or hear. She can actually add more things to the backlog, knowing that I'm a cautious estimator. And then the opposite, of course, is also true.

07:50

Once we execute, we will actually build the items in the sprint for that, let's just say two weeks. That's the most common one that people use.

07:59

At the end of that period, the code is going to production, so every sprint should end with a new set of features that go into your production environment.

08:11

Then once you execute a move that coat to production, then you go ahead and have ah, Sprint Review or Sprint reflective and you talk about Well, I thought I could get 30 items of work done. I only got six or 10 or 40 year or whatever and you look at OK, so how do we self correct our team

08:28

when we planned for the next sprint? To get even better at are estimating skills, so we want to continue to refine our estimating skills

08:37

in the beginning of every sprint as well, or try at the end of every Sprint items that weren't complete. They go back into the bucket. So when you start planning for Sprint number two, let's say

08:46

an item that you may have thought was important. Something has changed in your environment, and now all of a sudden it's less important. So it's not even gonna make it into sprint to it's gonna wait for Sprint three or four.

08:58

So in that way we respond to the complex environment that we're operating in by being able to change very rapidly in this case every two weeks, literally, we could completely change the focus of our project.

09:13

And if you look at the picture on the right here, this is just showing you a sprint backlog over time so you can see our items that we want to build

09:22

the items that were actually published to our test environment and then the items that made it to production. And you can kind of start to see even as your scope increases, you're still able to accomplish items in your sprint backlog

09:39

real quick before I go into the summary also wanted to show you this other item here and this is just a example of this is Microsoft Dev Ops looking at sprints

09:50

and scrum within a different sort of dashboard. So you can see the work that's been assigned to me right here. And you can also kind of see how long has remained, how much time remains in the sprint, things that haven't been started but are on the backlog. And you can see over time

10:07

how productive this different sprints are. And you can kind of see the drop off in production as we got around the holidays.

10:15

And that's just an example of a different type of dashboard that you can use four sprint planning.

10:20

So in today's video, we covered Scrum and Sprint planning. The last picture here I want to show you was that self correcting is called a velocity chart and basically is showing you how

10:33

we estimated certain things we planned them and then we were able to accomplish all of those items or maybe a little bit mawr or maybe a little bit less and over time. The idea is that your velocity improves as you get better

10:46

at producing features for the production environment and also how