00:00:00 - Welcome to this series on scrum master preparation.
00:00:05 - Scrum is a very widely recognized agile development process.
00:00:11 - This nugget is going to introduce you not only to scrum but introduce
00:00:15 - you to the specifics of scrum master certification or the process
00:00:21 - to follow to become a scrum master.
00:00:26 - In this introductory series we're gonna cover the very high
00:00:30 - level of what scrum and scrum mastering is all about. We'll give
00:00:34 - you an overview of the scrum process. We'll describe the scrum
00:00:39 - roles of which the scrum master is one. But there are other key
00:00:43 - roles involve with scrum project work. We'll talk about the key
00:00:49 - principle of scrum development which is we develop in releases
00:00:53 - and within the releases we develop in individual sprints where
00:00:58 - a sprint has a very defined time box.
00:01:06 - Then we'll talk about some of the scrum rituals.
00:01:10 - You're going to hear or you've probably heard terms such as the
00:01:14 - daily scrum, the sprint review process, the retrospective, and
00:01:21 - so on. So we'll orient you to the various scrum rituals or processes
00:01:25 - to be followed in a scrum development project. And we'll talk
00:01:30 - a little bit about scrum management. There is management process
00:01:35 - in scrum and, again, there are probably a few terms that you've
00:01:38 - heard of such as the daily burn down chart, the story burn up
00:01:41 - chart and so on. That will give you an overview of what scrum
00:01:46 - management is all about because there is a management process
00:01:50 - in scrum. And finally, we'll talk about or differentiate the
00:01:54 - differences between scrum and other agile development processes.
00:02:00 - But, first, let's roll up our sleeves and focus on what is
00:02:04 - scrum. So probably the very hardest thing I had to do in this
00:02:09 - nugget series is to give a definitive definition of scrum.
00:02:14 - What is scrum? Is a systems development approach? Yes. Is scrum
00:02:21 - exclusive for systems development? Absolutely not. Anything
00:02:28 - and I even hesitate to use the word thing but anything you want
00:02:33 - to do that requires a level of work typically of a unique variety
00:02:39 - because scrum is not truly designed for routine day to day production,
00:02:45 - doing the same thing manufacturing widgets day in day out. That's
00:02:49 - not scrum. So I would start to say scrum is based on project
00:02:56 - based work,
00:03:00 - where a project is a unique undertaking to develop, to deliver,
00:03:06 - to produce something new and unique.
00:03:11 - Does it have to be software?
00:03:15 - No. Typically, when we discuss scrum and most of the approaches
00:03:20 - we're gonna discuss in this nugget series are based on software
00:03:25 - development undertakings.
00:03:27 - And I really struggle with using the word project because most
00:03:32 - agilist and most scrum specialist try to differentiate between
00:03:37 - what we do with scrum approaches and traditional project approaches,
00:03:43 - and that is very, very true. Scrum is very different than traditional
00:03:49 - approaches and we'll discuss that in a future nugget. But I
00:03:53 - will continue to largely call out the work we're doing within
00:03:58 - scrum as project based work simply because it's unique and
00:04:05 - it has a goal.
00:04:08 - So when I refer to projects, I'm talking about something, some
00:04:11 - piece of work, something that we're going to do that is unique
00:04:15 - and has a goal and requires work. So again I
00:04:21 - have found I use the word project most comfortably. As I say
00:04:26 - there are other scrumists, agilists who prefer to not use the
00:04:31 - word project only because the word project takes us into more
00:04:35 - the traditional mindset. But in the pure textbook definition
00:04:39 - scrum is project based work often associated with software but
00:04:45 - not always. You can do anything in a scrum world. So enough
00:04:50 - with the definition. What is scrum? Scrum is very mush iterative.
00:04:56 - If we are to find a single word, in my humble opinion, that defines
00:05:01 - what scrum is, it's iterative. We do the project in pieces.
00:05:10 - And in a true sense of scrum we will do a project in many,
00:05:17 - many, many pieces.
00:05:22 - Each release
00:05:24 - that we discussed in the introduction and we'll talk more in
00:05:27 - this nugget is a part of the project. Within each release we'll
00:05:32 - have a sprint or a number of sprints that make up a release.
00:05:36 - An the sprint is developing a piece of a project. So that's why
00:05:40 - it's iterative. It's many, many, many pieces. And we'll talk
00:05:44 - about that aspect throughout this entire nugget series.
00:05:49 - Another key differentiator of scrum is it's very lightweight.
00:05:54 - You'll see by the time we finish this nugget series, there is
00:05:58 - some very sound, some very complete, some very robust
00:06:05 - definitions of developing working in a scrum environment, but
00:06:12 - there's not a lot. There is not a lot of memorization, there
00:06:16 - is not a lot of process, there is not a lot of predefined forms.
00:06:20 - As a matter of fact, there are no predefined forms associated
00:06:24 - with scrum. So it's very lightweight. It's easy to learn.
00:06:31 - Scrum is very, very easy to learn, but it's also hard to master.
00:06:38 - I hope by the time we finish this nugget series you have absolutely
00:06:42 - done all of the learning and are even well on the way to mastering.
00:06:48 - As I've already said, it's very simple to understand
00:06:52 - and it's based on these three principles.
00:06:56 - Transparent. There is nothing hidden.
00:07:03 - There's no traditional now the team is gonna go away for a period
00:07:08 - of time, two weeks, two months, et cetera, et cetera, and we're
00:07:12 - going to do some work and just trust us. There's none of that.
00:07:15 - Everything we do in a scrum environment is extremely transparent
00:07:20 - and, as we'll discuss in just a moment when we get into the roles,
00:07:23 - there's going to be a product owner.
00:07:27 - And the product owner represents the business.
00:07:31 - And the product owner is part of the scrum team. And the product
00:07:39 - owner is expected to participate
00:07:43 - daily in the scrum activity. So if you have your product owner,
00:07:51 - if you have the business sitting with the team for a significant
00:07:56 - part of everyday, there is no ability to be non-transparent.
00:08:02 - So scrum is designed to be extremely transparent. We want that
00:08:06 - product owner, we want them involved, we want a feedback, and
00:08:10 - we want to adapt and adjust
00:08:15 - which is the flexible and adaptable.
00:08:18 - And quality is built in. A lot of people, when they look at
00:08:23 - a scrum process or they first hear of scrum process and says,
00:08:27 - yeah, that's just the Wild Wild West. We just have a bunch rogue
00:08:31 - programmers out there writing code as they see fit and calling
00:08:36 - it scrum. It's absolutely not the case. Quality is built in throughout
00:08:43 - scrum. Each one of our iterations, each one of our sprints, and
00:08:49 - each one of our releases has the expectation that we're delivering
00:08:54 - functional, tested,
00:09:01 - implementable code. Or if you're interested in using scrum for
00:09:10 - non-development approach, each sprint results in meaningful results
00:09:16 - that the business can choose to use at the end of each sprint.
00:09:22 - So transparent, nothing is hidden. We want full active participation.
00:09:28 - We build quality in. It's not the Wild Wild West. It's tested
00:09:33 - implementable code at every step of the process. And, as we discuss
00:09:39 - some of the agile process that we're gonna apply continuous
00:09:43 - build, continuous integration, test driven development. What
00:09:48 - we deliver in a scrum environment is quality and it's flexible
00:09:52 - and adaptable.
00:09:54 - Because our sprints
00:09:57 - are short,
00:10:00 - if we find we made some mistakes, if we find our approach is
00:10:05 - not correct, if we find we need to fix things at the end of each
00:10:09 - sprint, we have a retrospective and in the retrospective we have
00:10:14 - the ability to be flexible and adaptable to improve continuous
00:10:18 - process improvement.
00:10:21 - So with this relatively brief introduction to scrum, I hope
00:10:25 - I've whetted your appetite on scrum and that you're ready to
00:10:28 - continue through this introductory nugget and certainly through
00:10:33 - this entire series to better understand scrum and to be better
00:10:37 - prepared to take your scrum master certification.
00:10:41 - So consistent with the fact that scrum is lightweight and easy
00:10:46 - to understand, there are five main roles defined in a scrum process.
00:10:54 - The key role
00:10:57 - is the scrum master. And I hesitated to say the key role is because
00:11:02 - most people will suggest the product owner is the key role in
00:11:06 - a scrum project.
00:11:09 - For the sake of this nugget series, I'm saying the key role is
00:11:12 - the scrum master because that's why we're developing, that's
00:11:16 - why we're taking this series, is to understand what scrum mastering
00:11:21 - is all about and to prepare you to become a certified scrum master.
00:11:27 - The scrum master is not
00:11:30 - a project manager.
00:11:35 - The scrum master is a guide.
00:11:39 - The scrum master is a facilitator.
00:11:44 - The scrum master may be a participating team member.
00:11:54 - The scrum master has no authority,
00:12:00 - but a lot of influence.
00:12:07 - I still believe the scrum master is key to the success of scrum
00:12:12 - processes because without any effective scrum manager filling
00:12:17 - these roles of the guide, the facilitator,
00:12:20 - able to work in a non-authoritative manner, but to influence
00:12:25 - the team and guide the team success,
00:12:28 - again, I believe the scrum master is certainly a key member of
00:12:34 - the scrum development team. If not the key as I say, a lot
00:12:39 - of other proponents of scrum will say the product owner is the
00:12:43 - key role because the product owner is the person with the authority
00:12:50 - on what
00:12:53 - is done.
00:12:55 - And that's where the product owner's authority stops. The product
00:12:59 - owner defines
00:13:01 - what it is the team is gonna develop. The product owner creates
00:13:06 - things called user stories. The product owner provides the details
00:13:11 - around what a user story is. And we'll talk much more about a
00:13:15 - user story later in the series. But the user story basically,
00:13:19 - again, identifies the what
00:13:21 - and the product owner identifies the priority
00:13:28 - in which the whats are gonna be done. And the product owner provides
00:13:33 - all of the details that the team needs to complete the whats.
00:13:38 - The team has the authority
00:13:44 - on how
00:13:46 - they accomplish the what.
00:13:50 - So the team is the people who work as a self-organizing,
00:13:56 - self-managing, self-controlled
00:14:01 - unit. There is no project manager in scrum. There is self-organizing,
00:14:08 - self-managing team that collectively determine how they're going
00:14:15 - to complete all of the work that the product owner has identified
00:14:18 - that needs to be done.
00:14:21 - The scrum master guides, facilitates, and influences the team,
00:14:26 - influence the businesses, and to me one of the key
00:14:30 - roles of the scrum master is removes the roadblocks to allow
00:14:34 - the team to get the work done. And these three are really the
00:14:39 - core team,
00:14:42 - and they're all participating members. As I said, we have transparency.
00:14:48 - The product owner is part of the team. The team does the work.
00:14:53 - And the scrum master ensures the team works in a scrum-like method
00:15:00 - and that is literary the core team. We have two other roles
00:15:05 - identified SME�s, subject matter experts. Subject matter experts
00:15:11 - are not part of the team. Subject matter experts are called in
00:15:16 - as needed.
00:15:19 - In a utopia world we would not need any SME�s because the product
00:15:25 - owner is all-knowing, all-seeing, all-wise.
00:15:30 - In most real life business environments a single person, the
00:15:35 - product owner, is not all-knowing, all-seeing, all-wise, so therefore,
00:15:39 - there will be instances where the product owner says, you know,
00:15:42 - I really don't know that answer, why don't you call Susan? And
00:15:45 - Susan becomes the
00:15:48 - SME. And then, finally,
00:15:51 - we have another key person and that's the business owner. That's
00:15:54 - the person with the dollars. That's the person with the need.
00:16:00 - And the product owner and the business owner may be one person
00:16:04 - but often not, the business owner is typically manager
00:16:10 - who has the power and the authority to commit organizational
00:16:15 - resources, i.e. dollars to the project, and managers don't have
00:16:20 - the time to sit with the team four hours every day to work on
00:16:25 - the scrum approaches. So the business owner appoints a product
00:16:30 - owner who does the day to day interaction with the team. The
00:16:35 - product owner typically organizationally
00:16:38 - reports to the business owner. And, typically, the product owner
00:16:42 - reports to the business owner from a project results viewpoint
00:16:45 - as well. And that's it. Those are all of the roles associated
00:16:51 - with scrum. Now, we have an entire nugget that's gonna go through
00:16:55 - the roles and responsibilities of these team members in much
00:16:58 - more detail, but at an introductory level these are our scrum
00:17:02 - roles. And if you'll excuse my drawing, I know I'm not the
00:17:06 - most artistically talented in the world, this diagram to me represents
00:17:11 - the concept of releases in sprints.
00:17:16 - Overall, this black area, and I deliberately did not draw this
00:17:20 - as square or regular object because projects are typically not
00:17:25 - that well defined. There's typically a lot
00:17:30 - changes, flexibility, well we're not gonna do this little piece
00:17:34 - here because that's better done inside the project and there's
00:17:38 - a significant amount of work here that's, again, business process,
00:17:42 - manual activities, as opposed to everything inside the black
00:17:48 - object is the product that our scrum team is gonna develop. And
00:17:56 - the developing this product may take a considerable amount of
00:18:00 - time. It may take six to 12 months
00:18:04 - to do all of the work associated with developing that product,
00:18:09 - taking on six to 12 months delivery as a single delivery is a
00:18:15 - traditional development project, and we know scrum is not a traditional
00:18:18 - development project because it's iterative with multiple releases
00:18:22 - and multiple sprints. So the business owner and the product owner
00:18:28 - work together to develop a release strategy. And they say this
00:18:33 - can be release number one and this can be release number two
00:18:37 - and release number three and so on. So if we deliver this functionality
00:18:42 - here, there's business value, let's call that a release. And
00:18:46 - then we augment that with some more business value here. Let's
00:18:50 - make that a release. So we'll release may be one to two months
00:18:55 - in length.
00:18:57 - And that, again, is far too much timeframe for a traditional
00:19:03 - scrum approach,
00:19:05 - so then we take each release and we break it into number of sprints.
00:19:09 - So this is sprint number one, sprint number two, three, and so
00:19:13 - on. And these sprints are in very short
00:19:18 - timeframes, where I am hesitating to tell a defined number for
00:19:25 - the length of a scrum sprint because there is some flexibility.
00:19:31 - But, typically, a scrum sprint is somewhere in the one to four
00:19:35 - week rage where, again, typically,
00:19:39 - a lot of projects don't work at the extreme so there's not a
00:19:42 - lot of sprints that are a week long or not a lot of scrum development
00:19:47 - approaches that take only one week sprints, nor are there a lot
00:19:51 - that take as much as four weeks because we lose some of the adaptability
00:19:55 - and flexibility so most sprints are in the two to three week
00:19:59 - window. And in each one of these sprints we deliver a little
00:20:04 - piece of the overall product. And when we combine sprints together,
00:20:13 - we get a release. And the release gives significant business
00:20:18 - value and, when we build all of the releases, we get the entire
00:20:22 - product. Now, a key concept of releases in sprints and scrum
00:20:29 - approaches in general is when the business owner and the product
00:20:34 - owner did the original plan this is what they thought the product
00:20:39 - was gonna look like but partway into it the product vision is
00:20:44 - going to change and we start to build that piece out there and
00:20:48 - we start to
00:20:50 - take this piece out and we build it and we reduce functionality
00:20:54 - and so on. And in a traditional approach, this is all done through
00:20:58 - change management and formal approval and formal authorization
00:21:03 - and work to do all of that. None of that happens in sprint because
00:21:07 - all of this change is outside of our current sprint. So if
00:21:13 - the business wants to add more functionality, we'll get to it.
00:21:17 - When's that schedule? Oh, that's gonna be in release number six,
00:21:20 - great. The business decided to remove functionality and that
00:21:24 - was gonna be done in release number five, awesome. So now, release
00:21:27 - number five can do this piece over here oops, five not two.
00:21:34 - So this is again part of the adaptability and flexibility of
00:21:39 - using scrum processes is it lets the business adjust and flex
00:21:45 - and deliver exactly what it is the business needs as business
00:21:50 - change happens and as the business requirements evolve.
00:21:56 - And consistent with being lightweight there are very few scrum
00:21:59 - rituals we need to concern ourselves with. There are four main
00:22:04 - scrum rituals and I presented this a little out of order. I presented
00:22:09 - the daily scrum first because my expectation is that's the first
00:22:13 - ritual you probably have heard off. That's the thing people think
00:22:17 - of most when they think of scrum development. And that's the
00:22:21 - daily scrum and this is your 15 minute stand up meeting
00:22:29 - where the team meets on a daily basis, hence, the term daily,
00:22:35 - for no more than 15 minutes. And in order to try to keep it to
00:22:39 - 15 minutes we recommend that this be a stand up meeting. If you're
00:22:44 - standing up and getting tired on your feet, you're not gonna
00:22:47 - be as prone to talk as opposed to, if you're sitting in comfy
00:22:51 - chairs with lots of sweets sitting on the table and some nice
00:22:56 - fresh coffee at the back, your 15 minutes stand up meeting quickly
00:23:00 - extends to an hour and a half because people just simply want
00:23:04 - to enjoy the soft chairs and the donuts and the fresh coffee.
00:23:08 - So, idea of the daily scrum, 15 minutes max, stand up, get
00:23:14 - it done and is what did we do?
00:23:18 - We do yesterday, what are we gonna do
00:23:25 - to do today and issues,
00:23:28 - problems, quick round the table, talk to every team member, awesome,
00:23:36 - we know what's going on. Joe, can you work with Betty to help
00:23:40 - Betty accomplish what she's gonna do? Fred, how did this go yesterday,
00:23:43 - did that approach work? Awesome. Why don't we try that going
00:23:46 - forward and so on and so on? It's a perpetual process improvement
00:23:52 - to ensure the team is on track to achieve the objectives of the
00:23:57 - sprint. The first ritual that we do in scrum, so again literary
00:24:02 - it should have happened up there, is the planning meeting. And
00:24:07 - the planning meeting actually is where the business
00:24:12 - requirements are presented, where the product owner selects the
00:24:16 - stories that are next most important to the business. Story 15,
00:24:22 - story 36, story 49, and story 2 are the next most important stories,
00:24:29 - pieces of business functionality that I want the team to focus
00:24:32 - on over the next sprint. So part one of the planning meeting
00:24:36 - is we select the stories.
00:24:39 - And when I say we select the stories, the product owner selects
00:24:43 - the stories based on priority. And in the second half of the
00:24:47 - planning meeting the team validates
00:24:52 - that they can accomplish the story selected, that there's enough
00:24:55 - information at hand, that they understand the stories well enough
00:24:59 - to do the work, that there's enough time, that the environment
00:25:03 - is prepared, et cetera, et cetera. So with the planning meeting
00:25:06 - done, we then start the sprint
00:25:10 - two to three weeks on average
00:25:15 - and we have a daily scrum for everyday of those two to three
00:25:19 - weeks where we ensure that we're still on track
00:25:24 - for our approach that we've delivered for the sprint.
00:25:28 - At the end of the sprint, we do a scrum review, where we represent
00:25:33 - the results.
00:25:38 - So business product owner, you asked us to do these stories,
00:25:43 - we're going to have a little show and tell. We're gonna show
00:25:46 - you the results, we're gonna prove to you that we achieved everything
00:25:51 - you asked us to do. Is that acceptance test? Kind of. Presenting
00:25:57 - the results should be short and sweet. This should not take a
00:26:00 - lot of time. We do not expect formal Power Point presentations.
00:26:05 - It's literary a roll up the sleeves and presents the results.
00:26:09 - Get confirmation that you have achieved the results, the expectation
00:26:13 - of the sprint, and declare the sprint done. And then, finally,
00:26:17 - have a quick retrospective to say, what worked,
00:26:24 - what didn't work,
00:26:28 - and start the process improvement.
00:26:31 - And the last key aspect to scrum work is there is a scrum management.
00:26:36 - Like everything else in scrum it's very lightweight.
00:26:41 - There aren't project management plans, there aren't formal Gantt
00:26:44 - schedules, there aren't most of the things we typically associate
00:26:48 - with project management, but there is scrum management at a very
00:26:53 - lightweight. And probably one of the main scrum management tools
00:26:57 - is the burn down chart. How well are we doing? Here is a graph
00:27:03 - for the sprint, day one, day two, through day
00:27:08 - ten or day 15, depending on whether there are two or three week
00:27:11 - sprint. Here's our objective. We wanted to do 14 stories. At
00:27:16 - the end of day one how many stories, at the end of day two, and
00:27:20 - so on, and we had a little lull in there where we had some complex
00:27:24 - stories and we're tracking our progress to see if we accomplished
00:27:29 - the expectations of the scrum.
00:27:34 - Talked about stories already. The story curds is where the
00:27:38 - product owner
00:27:43 - defines the whats.
00:27:47 - We don't do a large analysis document. We do a number of story
00:27:52 - curds. And most people recommend story curds are handwritten,
00:27:59 - so hopefully, your handwriting is better than mine, on index
00:28:02 - cards. And this index cards are used with thumbtacks and maintained
00:28:10 - on a peg board or corkboard. But the story curds are part of
00:28:16 - the management where we identify the whats that's gonna be required
00:28:20 - and we combine the story cards on that corkboard to give us the
00:28:25 - product release backlog.
00:28:29 - So here are all of the story cards that are required to satisfy
00:28:34 - all of the whats. The product owner goes to the product backlog
00:28:40 - as part of sprint planning and selects the next hire urgency
00:28:45 - prioritized stories and presents them to the team.
00:28:49 - We use that to develop the sprint backlog. The sprint backlog
00:28:53 - is obviously the input to the burn down chart and it identifies
00:28:58 - the 14 stories
00:29:01 - that we want to accomplish in the sprint. And the final aspect
00:29:05 - that we haven't discussed yet in this nugget as part of scrum
00:29:08 - management is this principle of velocity.
00:29:12 - How long
00:29:16 - does or is a story?
00:29:20 - How much work is required to complete the story and how much
00:29:26 - work can the team do
00:29:32 - in a sprint?
00:29:37 - So with this concept of velocity we're able to take that sprint
00:29:42 - backlog, validate that we have the ability to complete all the
00:29:46 - stories that the business has selected, and we can use our velocity
00:29:51 - to track how well to ensure the predictability of our burn down
00:29:57 - chart is allowing us to achieve our expectations of completing
00:30:03 - the sprint in ten days. And in a nutshell, that's it for scrum.
00:30:09 - Scrum is all about developing an agile approach to software development,
00:30:16 - which leads us to our next discussion point, what is the difference
00:30:20 - between scrum and agile? So where does agile fit in? Well, my
00:30:25 - first statement is scrum is agile. Agile to me is a lightweight
00:30:34 - software development process.
00:30:41 - Scrum is a lightweight software development process. The big
00:30:46 - distinction I make between scrum,
00:30:49 - and scrum is very focused on the "management",
00:30:55 - and I will definitely put that in quotation marks and I try to
00:30:59 - write it in the small of letters as possible and still allow
00:31:02 - you to read my horrible handwriting because scrum is management
00:31:07 - light as we've experienced, but scrum is the management process.
00:31:13 - It's identifying of the roles. It's identifying
00:31:19 - the rituals that we're gonna go through. It's identifying of
00:31:22 - the artifacts we're going to produce. So scrum is a way
00:31:27 - to develop lightweight software
00:31:30 - and scrum applies
00:31:33 - at your project discretion most of the agile development processes
00:31:38 - for software development such as test driven development. Write
00:31:43 - the test cases then write the code to ensure that test cases
00:31:47 - are successful. Ensures we're delivering quality. Where appropriate,
00:31:52 - scrum supports pair programming.
00:31:56 - Scrum absolutely expects that we're gonna do refactoring, that
00:32:00 - we are going to have technology debt, that we going to have to
00:32:03 - do process improvement, that, as we add new functionality in
00:32:07 - future sprints or future releases, that we're gonna break things
00:32:11 - and we need to do improvement, so we're gonna have refactoring
00:32:15 - recognizing the technology debt is inevitable in a lightweight
00:32:22 - incremental iterative software development process. Scrum recognizes
00:32:28 - the technology debt exists and must be removed through future
00:32:32 - sprints and future releases and absolutely supports the concept
00:32:37 - of continuous integration. You complete a piece of code, you
00:32:41 - check it into the repository, you run the build, and you make
00:32:44 - sure you didn't break anything. So the distinction between
00:32:49 - scrum and agile is scrum is one of the agile processes. Scrum,
00:32:56 - I believe, is one of the most popular and most successful agile
00:32:59 - processes because scrum has this very small letter, quotation
00:33:05 - marks management process, and when we apply our scrum processes
00:33:11 - and other proven agile development techniques, I believe we have
00:33:17 - an absolute recipe for success.
00:33:21 - So in this introductory nugget to the scrum master preparation,
00:33:25 - we provided a high level overview of scrum.
00:33:34 - We defined what scrum is. It's a lightweight
00:33:40 - iterative process
00:33:44 - with some very light management to help us develop
00:33:49 - traditional software but any project in an iterative flexible
00:33:54 - manner. We discussed scrum roles, the scrum master,
00:34:02 - the product owner,
00:34:07 - and the team
00:34:09 - as the three core roles to participate in a scrum project. We
00:34:15 - talked about releases and sprints combining to deliver the specific
00:34:19 - requirements of the business. We identified a number of scrum
00:34:24 - rituals where the daily scrum,
00:34:29 - the planning meeting,
00:34:32 - the scrum review,
00:34:37 - and the scrum retrospective
00:34:43 - allows us to keep the scrum project under control consistent
00:34:48 - with scrum management where we provide a very lightweight management
00:34:52 - approach. And we concluded with a review of scrum is one adaptation,
00:34:59 - one method of being agile.
00:35:02 - So with this introductory nugget concluded, I hope you've remained
00:35:07 - interested in scrum development that you continue your interest
00:35:12 - in becoming a scrum master. And I encourage you to continue through
00:35:19 - the rest of this nugget series and further explore and further
00:35:23 - understand this exciting world of becoming a scrum master. This
00:35:29 - concludes our nugget and scrum master preparation. I hope this
00:35:33 - module has been informative for you. And thank you very much
00:35:36 - for viewing..