Scrum Certification

Preparation for Scrum Master, Product Owner, and Scrum Team Certification

by Steve Caseley

Total Videos : 27 Course Duration: 15:18:45
1. Introduction to Scrum (00:35:37)
2. Scrum versus Traditional Development (00:32:21)
3. Scrum Roles (00:38:45)
4. Scrum Meetings (00:38:11)
5. Scrum Artifacts (00:38:58)
6. Scrum Master (00:32:16)
7. Product Vision and Product Backlog (00:41:06)
8. What is done? (00:27:58)
9. Release and Sprint Planning (00:34:32)
10. Scrum Estimating (00:34:25)
11. A Sprint (00:39:50)
12. Daily Scrum (00:25:42)
13. Tracking Progress (00:33:06)
14. Dealing with Changes (00:25:22)
15. The Product Owner (00:31:35)
16. Sprint Review and Retrospective (00:31:28)
17. Backlog Grooming (00:34:45)
18. Writing User Stories (00:34:28)
19. Team and Business Dynamics (00:43:17)
20. Technology and Process Debt (00:35:45)
21. Agile Development Techniques - 1 (00:30:31)
22. Agile Development Techniques - 2 (00:28:22)
23. Delivering Large Projects with Scrum (00:36:43)
24. Distributed Scrum (00:35:24)
25. Scrum Process Improvement (00:24:38)
26. How to Deal with Organizational Resistance (00:41:58)
27. How to Get Started with Scrum (00:31:42)
This course provides a comprehensive review of the Scrum development approaches and the knowledge and skills needed to become a Certified Scrum Master.

Trainer Steve Caseley provides an overview of Scrum, including the roles, activities and project management tools. Steve breaks down the specific duties of each Scrum Role: Scrum Master, Product Owner and Scrum Team, as well as the Scrum rituals that form the core of Scrum. The course also explores the similarities and differences between Scrum and traditional development approaches and examines the six different Scrum certifications from the Agile Alliance.

This training has been approved for Category A PDUs. For a listing of how many PDUs are earned for this training, please visit our PMI R.E.P. FAQs on our Forum.



Related area of expertise:
  • IT project management

Introduction to Scrum

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..

Scrum versus Traditional Development

Scrum Roles

Scrum Meetings

Scrum Artifacts

Scrum Master

Product Vision and Product Backlog

What is done?

Release and Sprint Planning

Scrum Estimating

A Sprint

Daily Scrum

Tracking Progress

Dealing with Changes

The Product Owner

Sprint Review and Retrospective

Backlog Grooming

Writing User Stories

Team and Business Dynamics

Technology and Process Debt

Agile Development Techniques - 1

Agile Development Techniques - 2

Delivering Large Projects with Scrum

Distributed Scrum

Scrum Process Improvement

How to Deal with Organizational Resistance

How to Get Started with Scrum

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Steve Caseley

Steve Caseley

CBT Nuggets Trainer

Certifications:
PMI-PMP, PMI-ACP, PMI-SP, Project+

Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development


Course Features

Speed Control

Play videos at a faster or slower pace.

Bookmarks

Pick up where you left off watching a video.

Notes

Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Share

Stay Connected

Get the latest updates on the subjects you choose.


  © 2014 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS