Gain in-depth knowledge for passing your exam with Exam-Labs CSM-001: Certified Scrum Master certification video training course. The most trusted and reliable name for studying and passing with VCE files which include GAQM CSM-001 practice test questions and answers, study guide and exam practice test questions. Unlike any other CSM-001: Certified Scrum Master video training course for your certification exam.

Chapter 02 - Introduction to Scrum

15. Scrum Scalability

One of the key constraints associated with Scrum is that a particular Scrum team has to be small in order to be effective. A scrum team really should be no larger than ten people and no smaller than five or six. And in order to be able to handle the scalability required for larger programs, we're going to introduce the idea of a Scrum of Scrum, effectively the ability for different Scrum teams to collaborate together in order to be able to break up the sets of resources and deliverables required for a larger project. One of the other ideas is the notion of a Scrum guidance body. The purpose of a Scrum guidance body, of course, is to gather lessons learned across all of the different Scrum teams and all of their projects we're working on so that we can identify good practises that the organisation can leverage and use to improve the velocity and performance of all of the Scrum teams in the organization.

16. Lesson: Scrum Concepts & Principles

In this lesson, we're going to take a look at some of the core concepts and principles of Scrum, talk a little bit about how the different aspects help us support project management, and then talk about the processes that are used within the Scrum lifecycle to effectively carry out and deliver solutions for customers. Let's take a look at how these are going to work.

17. Scrum Principles

There are six key principles that underpin Scrum and really help us make it work. The first of these is the idea of empirical process control: if we want to know how a project is doing, we want to actually look at what we have. So empiricism essentially means looking at the results. Tangibly, what do I have in front of me? And using that as a point of feedback, in fact, we should evolve a solution to deliver on a set of customer needs. The principle of self organisation essentially means that within Scrum, the Scrum team works together to figure out how they're going to carry out and deliver on customer requirements and user stories. That there is no project manager, and there are no specific roles and responsibilities that will be assigned by someone on high, but that the team has to figure this out together. This obviously creates a very heavy emphasis on collaborative effort. The team works together to produce complete solutions. We want to be able to focus the team's effort on the solutions that have the highest value for the customer. So when we introduce the notion of a product backlog, for example, the goal here is to prioritise that product backlog in a way that reflects the highest value for the customer. First, in order to successfully carry out our work, we're going to make heavy use of time-boxed meetings where we're very disciplined about how much time and what kinds of activities we're going to engage in within particular meetings. Essentially, to minimise meeting time and enable the Scrum team to perform the work intended, And last, and certainly not least, the focus is ruthlessly on iterations of development that, in short, are going to evolve over time. And so rather than thinking of one big monolithic project that delivers one big monolithic solution, we expect that the customer's requirements are going to change, that risks are going to change, and that opportunities are going to present themselves. And then we want to be able to identify a manageable iteration, generally two to four weeks, that we can use to carry out and produce high-value solutions again and again over time. And that is how we then focus on changes based on value-based prioritization. Let's take a look at each one of these principles in some more detail. Yeah.

18. Empirical Process Control

So the first part of this is the notion of empiricism. Empiricism simply means that I want to be able to use techniques like inspection to actually have stakeholders look at what we're doing and provide feedback. Right? So if you think about the key aspects of any Scrum project, it's really driven by these three notions of transparency, inspection, and adaptation: that all facets of the work of the Scrum team are fully observable by anyone through visibility at meetings. Access to various artefacts and various types of reports are what we call "information radiators" that people can see at any moment in time so that everybody has visibility into what's going on. Likewise, we want to have consistent and regular feedback from various stakeholders on solutions and how, in fact, those solutions may need to evolve to meet customer needs. Finally, we want to be able to evolve the solutions appropriately as the customer's needs change, as risks change, as requests for change come in, or as various expert guidance provides us with abilities to do things better, faster, and more cost effectively. So I like to think of this as the triangle that really underpins all of Scrum. How do we create sets of practises that facilitate transparency, that invite inspection from all stakeholders to the work that we're redoing, and then be able to make adaptations over time in a way that allows us to continue to evolve solutions to meet changing customer needs?

19. Self-Organization

The second of the key principles is self-organization. Scrum is fundamentally designed witha basic assumption in mind. People who are working seek opportunities to really make their own way to be able to take responsibility for driving solutions. The leadership associated with a Scrum-based project is based on the notion of a servant leader, and being an effective leader in a Scrum project isn't positional; it's about making the team more effective. How can I remove roadblocks in a way that enables the team to perform more efficiently, more effectively, and deliver better results for the customer? And so when we look at how Scrum teams are organized, The role of the scrum master and the product owner All of these are fundamentally driven around how we gain better buy-in and ownership of the solution from the team. how we improve the team's morale and motivation over time. and how we create space to allow people to be innovative and creative in coming up with new potential solutions to problems that are presented to them.

20. Collaboration

The notion of collaboration is certainly not new to anyone watching this course. But we want to be able to set up environments where the teams can work together to produce a better solution than they might be able to produce in various silos. In order for that to actually happen, certain things have to take place. The first one is basic awareness. Do we have meaningful visibility into who's got what at any moment in time and how the various teams are working together to produce solutions? Likewise, we have to be able to effectively articulate how work gets partitioned and then reintegrated to produce whole, working solutions. Last but not least, we want to be able to appropriate certain technologies as needed to support various need sets. And we want, wherever possible, to be able to reuse technologies or various approaches in a way that's going to help us gain some efficiencies and deliver a better solution for the customer. So by creating these types of collaborative environments, it creates an environment where we get constant clarification of customer requirements. By having broad visibility, we reduce the need for change. We identify risks and identify potential mitigations for those risks on a regular and frequent basis. And it provides us an opportunity to drive improvements in the product as well as improvements in our processes that we use now in order to actually create these environments. Scrum suggests very strongly that the teams, wherever possible, be colocated. This doesn't mean that you can't have virtual teams doing Scrum, but you'll find that the efficiencies and the value of Scrum are amplified quite greatly if you can have the teams co-located together.

21. Value -Based Prioritization

So one of the unfortunate truths of any project is that customer needs and wishes change—and they change all the time. They shift in response to external factors such as legal and regulatory issues, competitive threats, customer needs, expectation shifts, and even internal activities. And so when we think about the various features or capabilities of a particular solution, they're not fixed for almost any kind of solution. Almost all projects have a basic dynamic around how requirements need to change over time to manage the changes that happen in the business environment. And so the way that Scrum deals with this is through the creation, maintenance, and grooming of what we'll call a prioritised product backlog. In short, here are all the features we might want, here are all the changes we might want, and here are all the risks that we might want prioritised based on our wishes and their value to the business. And we're going to continually evolve and perhaps reorder that based on changing needs for business value, the availability of certain risks, as well as the various dependencies inherent in the work inherent.And so what we want to be able to do is ensure that the Scrum team is working on the things that have the highest value for the customer at that time, while acknowledging that there are many other things we would like to do, but we will prioritise the highest value items first. And, of course, as the world changes, what becomes the most valuable thing continues to evolve over time.

22. Time –Boxing

for all of you with a substantial level of work experience. You are, I'm sure, quite aware that one of the most valuable resources you have is your time. And so one of the things we want to do is value time and how development teams and other work teams collaborate to deliver solutions. So many different types of scrum activities are very specifically and intentionally constrained to a particular amount of time. In particular, various kinds of meetings—the daily standup or daily scrum, the Sprint planning meeting, the Sprint review meeting, and the Sprint retrospective—are very explicitly time boxed based on this particular set of customer needs. The key benefits to time boxing are improved efficiencies because we're spending more of our time focusing on the development of the solution, being able to reduce our management overhead associated with actually holding and carrying out these meetings, and being able to improve our team's ability to perform and deliver more user stories and more value in each particular scrum. So there are a number of different time boxes used within Scrum. A sprint itself generally runs from two to four weeks. Most of the frameworks cap this at 30 days. Some of the frameworks may go as long as six weeks, but it's certainly my recommendation that you keep them within two and four weeks. The daily stand-up meeting is particularly time-boxed at 15 minutes. The sprint planning meeting is time boxed at 4 hours for a two-week sprint and 8 hours for a one-month sprint review. That is, 1 hour per week, as in this case for a sprint retrospective. And we'll introduce all of these in more detail when we talk about the different aspects of a Scrum project.

23. Iterative Development

Iterative development essentially means that I'm doing my development in round, right? And so whether we use a two-week sprint or a four-week sprint as we work our way through a project, inevitably there are some fundamental issues that have to be dealt with at the beginning of a project. We may not have particularly good detail on the requirements. The customer may not have very good visibility into what the solution actually needs to look like. There may be situations where there are many solution deliverables that have to be provided over a long period of time, but where we would prefer to deliver higher-value deliverables right away if we can. There are going to be changes, and when changes need to occur, we may need to reprioritize the level of effort, the amount of work, and which work goes first. And so we want to be able to have a framework that's sufficiently flexible to support that. And then last, but certainly not least, we will continue to identify and have to manage risks and issues throughout the life cycle of the project. And we want to be able to do that in a way that's consistent with the rest of the work that we're trying to deliver and the value proposition for the customer. And so by using an iterative model, essentially breaking a development project into various sprints, we're acknowledging that these are moving targets. Even though the customer would prefer that they were not moving targets, they are. The customer's needs will change, and risks will change. And so we want to be able to use these capabilities to keep the team focused on how we deliver the most optimal value and the most optimised solutions to the customers as quickly as we can.

24. Scrum Aspects

The first of these is organization. When we go through the next section, you're going to see that a Scrum project really has just three core roles: the Scrum product owner, the Scrum Master, and the Scrum team. We want to be able to fundamentally focus on the business justification for the project. Why does this project have an appropriate business case? What's the vision behind us for the customer? And how do we focus our solution on the activities that are going to deliver the most benefit to the customer? Throughout the project, we want to be able to focus on delivering an effective level of quality in our solution so that we're not just delivering that particular sprint, but we're setting the table for successful future changes, future improvements to service, and additional features and capabilities the customer will want. Along the way, we want to be able to effectively integrate and manage the request for change and their ability to manage, identify, and mitigate risks as necessary. So the different Scrum aspects really describe how we, as Scrum teams, collaboratively manage the moving target in a way that helps us figure out who's got what and how we're going to effectively deliver solutions back for the customer. In this next lesson, we're going to take a look at the core Scrum processes. As you'll see, there are no fewer than 18 of them organised into five large groups: initiation, planning and estimation, implementation, review, retrospect, and release. Let's take a look at each of these briefly now.

Pay a fraction of the cost to study with Exam-Labs CSM-001: Certified Scrum Master certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including CSM-001: Certified Scrum Master certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide