Certified ScrumMaster® (CSM)

Certification Training
13778 Learners
View Course Now!

SCRUM @ High Level - Certified ScrumMaster® (CSM) Tutorial

1.1 SCRUM @ High Level

Hello and welcome to the introductory session of SCRUM from Simplilearn. Scrum is one of the most widely used techniques or methodology in the industry for the development of products and is in huge demand. You might have come across the term Scrum often while interacting with your colleagues or friends during the office projects and might be wondering what this is all about. Well to answer your queries, in this session, we are going to explain about Scrum at high level, for instance, what is scrum, where is it used, who has to use it, how is it used, etc. Let us look into the agenda of this session which will give you an idea as to how we will answer your queries.

1.2 Agenda

First, we are going to discuss Scrum history wherein we will address the beginning of Scrum and the current state. Then we will look into the definition of Agile and the different methodologies and how Scrum is connected with Agile followed by definitions of Scrum and different terms used under Scrum framework. The next part is about different roles played under Scrum and their importance. Also, we are going to address about the best practices of Scrum that we can learn from this session. After hearing the high level of scrum you may be wondering, “Am I the right person to take up the scrum course or certification?” Well, we will answer that query as well, when we discuss the target audience. Also, we will look into the different certifications provided available in Scrum. And in the end we are going to cover how Simplilearn will help you obtain the “Certified Scrum Master Certification” which we also call it as CSM. Now, let us look into the above discussed topics in detail in the following slides.

1.3 Scrum History

Let us begin with the history of SCRUM. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new approach to product development that would increase speed and flexibility. This was called as rugby approach. In the early 1990s, Ken Schwaber used this approach which became Scrum. .Jeff Sutherland, with John Scumniotales and Jeff McKenna, developed a similar approach at Easel Corporation, called Scrum methodology which they presented at the Business Object Design and Implementation Workshop. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. In 2001, Schwaber worked with Mike Beedle to describe the method in the book Agile Software Development with Scrum. Due to one of Ken Schwaber’s early papers which capitalized SCRUM in title, some companies implementing the process use it with capital letters, although the word in not an acronym. Now that you have an idea about the history of Scrum, where it came from, let’s look into the definition of Scrum in the next slide.

1.4 What is Scrum?

So, what is Scrum? Scrum is an Agile methodology and is by far the most popular Agile methodology practiced in industries. The term “Scrum” refers to the team huddles or clusters in rugby which happens just before the game begins. The scrum methodology follows the practices similar to that in the game of rugby. Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. It is used to manage complex product development. Scrum demonstrates the relative efficacy of your product management and development practices so that you can improve. It consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. In the recent years there has been a significant demand for Scrum awareness and scrum certification in the industry. As we said in the earlier slide that SCRUM is one of the methodologies used under Agile software development approach, likewise we are having different other methodologies that can be used in Agile. In the coming slides will see a few methodologies at the high level.

1.5 What is Agile?

We will understand Agile in this slide, Agile is most popular in software development approach and is based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It is a time-boxed iterative approach that promotes adaptive planning, evolutionary development and delivery, and encourages rapid and flexible response to change. Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Team composition in an Agile project is usually cross-functional and self-organizing, without consideration for any existing corporate hierarchy or the corporate roles of team members. Agile methods emphasize face-to-face communication over written documents when all the teams are in the same location. In the next slide we will see reasons why Agile is vital for an organization.

1.6 Why Agile?

Agile focuses on most important or high priority items and prevents waste. It produces working software quickly and also delivers value to the customer at the earliest. This helps to market the product fast and in time and also recognizes customer engagement. The feedback from customer is immediately incorporated in the next incremental release. Also there is flexibility in terms of prioritization of features based on customer or market demand. For more details please look into the website http://www.agilemanifesto.org In the next slide we will get an insight into different Agile methodologies.

1.7 Agile Methodologies

The different methodologies can come under the umbrella of two variants. One is lightweight approach and the second one is fuller approaches. Lightweight approaches are characterized by relatively fewer prescriptive agreements, whereas fuller approaches involve a lot more detailed guidance in terms of process prescriptions. Some of the lightweight approaches are Scrum, extreme programming, and crystal. Some of the heavyweight or fuller approaches are dynamic systems development method or DSDM atern which is quite popular in the UK, Agile unified process, which is an instantiation of the rational unified process for adapting it to Agile, and feature driven development or FDD. Let us address a few points about all these methods as our main focus of this session is on Scrum. Crystal clear can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical. The crystal family of methodologies focuses on efficiency and habitability as components of project safety. Crystal clear focuses on people, not processes or artifacts. Crystal clear requires frequent delivery of usable code to users, reflective improvement, and communication preferably by being co-located, personal safety, focus, easy access to expert users and technical environment with Automated Tests, Configuration Management, and Frequent Integration. Feature driven development also called as FDD is an iterative and incremental software development process. The practices are all driven from a client-valued functionality or feature perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner. The main goal of extreme programming or XP is to lower the cost of change in software requirements. With traditional system development methodologies, like the waterfall methodology, the requirements for the system are determined and often "frozen" at the beginning of the development project. This means that the cost of changing the requirements at a later stage in the project — something that is very common in the real-world — can be very high. The five core values of XP are communication, simplicity, feedback, courage, and respect. The Agile unified process or AUP applies Agile techniques such as test driven development (TDD), Agile modeling, Agile change management, and database refactoring to improve productivity. Dynamic systems development method (DSDM) is an Agile project delivery framework, primarily used as a software development method. Let us discuss about Scrum lifecycle in the next slide.

1.8 Scrum Life Cycle

The lifecycle of Scrum is based on the term sprint which is the heart of the Scrum. Sprint is a timebox typically of 3 to 4 weeks of planned activities. You may be wondering what is timebox! Don’t worry, we will cover timebox further in this course. Sprint has consistent duration and the next sprint starts immediately after the conclusion of the previous sprint. At the end of each sprint we are going to get finished work which can be for example a usable product. In the Scrum lifecycle there are different roles associated with it and different types of meetings are carried out. Apart from these we need to understand different terminologies used under Scrum. We are going to address all these parameters in the upcoming slide. In the next slide we will look into terminologies used in Scrum.

1.9 Terminologies used in SCRUM

Here are different terminologies used by the team who are managing or practicing the Scrum. So before starting projects which uses Scrum methodologies, one should be aware of all these terminologies to be in sync with the process and people. To list a few, terminologies like sprint, timebox, done, and release are frequently used. Other than these there are events and roles which will be explained during the later part. We are going address each one of them in the next slide.

1.10 Sprints

Let’s begin with basic definition of sprint. Sprint is an agreed time within which the team needs to complete an agreed upon set of deliverables. As we said earlier the duration of sprint which we call it as timebox is about 4 weeks. At the end of the sprint, the agreed software has to be delivered which is fit for use. One may be having the question, what happens when the agreed software is not complete; can the time line of sprint be extended? The answer is NO. Sprint deadline cannot be extended. But sprint duration can be changed during the course of the project, but not within the sprint frame itself. Hope you got the understanding of sprint. In the next slide we see about the definition and characteristics of time-box.

1.11 Timebox

Timebox is a fixed time limit to an activity or we can say that timebox is the duration fixed for an activity. The activity can be within sprint, meeting, review, etc. The important point to be noted here is that timebox for an activity remains constant while you can vary the scope of the activity. The timebox is non-negotiable attribute of the Scrum. That means to say that if there are ten features to be developed in a given sprint within certain timebox and if all ten features are not completed within this timebox, we can’t extend the duration, instead those features which are left out will be addressed as part of another sprint. There is no such thing as standard timebox, it depends on the size, complexity, environment, etc. It can be 1 hour, 1 day, 1 week, 1 month, and so on. If in a given sprint, the activities couldn’t be completed on time, we can’t extend the sprint. The team determines how much functionality can be delivered in that fixed length of time and fixes the length of the iteration. In the next slide we are going to see some of the advantages of timebox.

1.12 Advantages of Timebox

Since time-box is based on the defined time which can’t be extended, it helps one to focus his or her attention on the job at hand for the specified period of time. Also defining a fixed time period and working diligently in a focused manner on the identified task, helps one to work smarter and harder and get more done which increases the productivity. Defining a fixed time period helps you identify how much work is done in the specific time and avoids the idling time. With this one can realize the time spent. It also helps one to be consciously aware of the time available to perform the task at hand. These are some of the advantages, in the next slide let us understand what release and release plan is from the Scrum perspective.

1.13 Release

In our day to day life we have heard about term ‘release’, for example, software release. But from the Scrum perspective, the concept of a “Release” has been removed. The idea being that each Sprint should be considered a mini-release. A release plan is essentially a roadmap of how the team intends to achieve the vision of the project by implementing the features laid down in the project data sheet and meeting the overall objectives for the project, while working within the constraints of the project. The release plan is an important artifact for the product owner, who with which can communicate to the project’s stakeholders about what they can expect from a given project. It also helps the team gain an understanding about the expectations and plan accordingly. A release plan is a guide-post that channelizes the energies of a project team in a particular direction. We will look into the concept of daily scrum in the next slide.

1.14 Daily Scrum

Each day during the sprint, a project team communication meeting occurs. This is called a daily scrum, or the daily standup. The main guidelines of the daily scrum or what we call as daily standup is that all members of the development team come prepared with the updates for the meeting. The meeting starts precisely on time even if some development team members are missing. The meeting should happen at the same location and at the same time every day. The next point is that meeting length is set to 15 minutes which we call it as timebox for the meeting; please recall this from earlier slides where we discussed timebox. And the last point about daily standup is, all are welcome, but normally only the core roles speak. Let us get an insight into the activities of daily scrum in the next slide.

1.15 Daily Scrum

It is a quick meeting for the team to get together and update each other about what is going on in the project. To keep the meeting short as discussed in the previous slide which is of no more than 15 minutes, the entire team stands for the duration of the meeting. Even if you have remote participants, they should stand as well. Each participant basically answers 3 questions as concisely as they can. The questions are: First, what they did yesterday? Second, what they intend to do today? Third, what is in their way (obstacles or blocking issues)? There are no conversations or discussions. If the team members do wish to collaborate and discuss further based on the data given, for example, a team member may want to help his colleague with an obstacle, then such conversation must be taken outside of the daily standup meeting so that they don’t end up wasting everybody’s time. One has to rememberthat the daily stand-up meeting is not a status meeting for the manager. It is for the team to report to each other and get in sync with each other. Let us understand user story in the next slide.

1.16 User Story

It is important to understand that the user story is basically a medium that facilitates “communication” about the requirements. Therefore, it contains concise information about the requirements. The details need not be too extensive but should be enough for the team to come up with estimates and define the acceptance tests for the story. The story is the starting point of communication about the details of a requirement and once they are understood and agreed, it represents an agreement between the development team and the customer about what the customer can expect from the implementation. In the next slide we will learn about the information the story card contains.

1.17 Story Card Information

Here is some information that can be captured on the story card per user story. Note that this is not really a fixed “prescription” – rather an indicative list that can be customized for your project. A story card should contain story identifier which is a number and a name, a short description not more than a couple of sentences that describes the feature from the customer point of view, story type “C” or “T”, which tells whether the story was requested by the customer or was it a technical story that the team voiced. For example, a feature request that comes from the customer is story type C, but a story to re-factor the code or support a new version of a hardware/software platform may come from the team and is of story type T. The next is estimated work effort which will be filled in by the team with the amount of effort required to deliver the story, then is the estimated value points which indicates how much “value” it delivers to the customer. The story card also includes requirements uncertainty which is nothing but how much variability can be expected in the requirements sometimes called the “exploration factor.” The next is story dependencies, which helps understand the implementation sequence by understanding how stories are dependent on one another. Finally, we have acceptance tests which are written on the back of the card that indicates how the story should be tested. Let us understand the meaning of “Done” in Scrum in the next slide.

1.18 Definition of Done

For any activity when we say it is done, it might carry different perspective to different stakeholders in the project. So before execution or implementation of an activity during the planning stage, one should clearly understand the meaning of done. When an activity can be said as “done” is an understanding or agreement between stakeholders. For examples a story is said to be “Done” when a design is completed and reviewed by the architect, coding is completed for 100% of the paths described in the story, testing is completed for the story, regression testing is done to ensure no unexpected impacts, all identified bugs are fixed, and finally technical and user documentation is updated for the added, deleted, or modified functionality. In the similar line, one can define DONE criteria for sprints or releases. In the next slide we discuss about product backlog.

1.19 Product Backlog

The product backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The term “Backlog” refers to the sum total of “things” the team can do that would be valuable to the customer. It may contain new features, modification to existing features, removing existing features, and work arising out of team preferences like refactoring, supporting new platforms, or even fixing product defects. The objective of creating the backlog is to expand upon and keep evolving the overall vision or direction for the product through continuous process of defining and elaborating the requirements. The common thread that binds everything in a product backlog is that all the work must result in adding value to the customer. The product backlog is defined in terms of user stories. All items in the backlog must be ranked in priority order. The product backlog needs to be well defined for the next 2 or 3 sprints and the rest could be defined at a high level and finally it is a “live” list maintained during the project. Let us look into sprint backlog in the next slide.

1.20 Sprint Backlog

The sprint backlog is the set of product backlog items selected for the sprint plus a plan for delivering the product increment and realizing the sprint goal. The sprint backlog is a forecast, i.e., it defines the work that will be performed to turn product backlog items into a “Done” increment. The sprint backlog is a plan with enough detail about changes in progress which can be understood in the Daily Scrum. As and when new work is required, it will be added to the sprint backlog. As the work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. The sprint backlog is a highly visible, real-time picture of the work that the team plans to accomplish during the Sprint. In the next slide we discuss about sprint planning meeting.

1.21 Sprint Planning

Let us revisit Scrum lifecycle picture to understand the context of sprint planning. There is a very important meeting right at the beginning of a sprint, where the teams with the help of the product owner selects stories from the backlog which it will be implementing in the current sprint. Getting into the rhythm of making good, reliable sprint plans is an important success factor for the team. We will continue with the sprint planning in the next slide.

1.22 Sprint Planning

In this slide, we will discuss about the goal of sprint planning meeting. The goal of the sprint planning meeting is for the team to make a “good commitment” about what they will deliver at the end of the sprint. The meaning of a good commitment is that everybody is clear about the goal and everybody believes that it is achievable. The goal of the sprint should be achievable without cutting corners or sacrificing on quality and further it should be achievable without sacrificing sustainable pace. Please do not plan on the whole team working overtime for the duration of the sprint. Especially in case of distributed teams, some sprint pre-planning and advance story grooming activity with the product owner helps to keep the planning session short. In the next slide we will discuss about ‘Sprint Review’.

1.23 Sprint Review

A sprint review is held at the end of the sprint to inspect the increment and adapt the product backlog if needed. When we say adapt, it is to adjust the product backlog so as to meet the same during the upcoming sprints. This is an informal meeting and happens in collaboration among the team. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings. Now considering the duration of sprint review, it is a four-hour time-boxed meeting for one-month sprints. Proportionately less time is allocated for shorter sprints. For example, two week sprints have two-hour sprint reviews. Some of the activities of sprint review are it identifies what has been “Done” and what has not been “Done.” It discusses what went well during the Sprint and also various problems in Sprint and their solutions. The team demonstrates the work that it has “Done.” A product backlog is maintained during the course. Team also provides information about each increment, it also provides details about project completion date based on progress made to date by the project. The result of the ‘sprint review’ is a revised ‘product backlog’ that defines the probable product backlog items for the next sprint. The product backlog may also be adjusted overall to meet new opportunities. In the next slide we will discuss about Sprint Retrospective.

1.24 Sprint Retrospective

Retrospectives are regular reviews of the team, by the team, to discuss how they are working. The sprint retrospective is an opportunity for the Scrum team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The sprint retrospective occurs after the sprint review and prior to the next sprint planning meeting. Sprint retrospective is a three-hour time-boxed meeting for one-month sprints. Proportionately less time is allocated for shorter sprints. The purpose of the sprint retrospective is to inspect how the last sprint went with regards to people, relationships, process, and tools. It also includes identifying and ordering the major items that went well and potential improvements. The purpose also is to create a plan for implementing improvements to the way the Scrum Team does its work. By the end of the sprint retrospective, the Scrum team should have identified improvements that it will implement in the next Sprint. Please remember retrospective is neither a ‘post-mortem’ nor it is about blaming. In the next slide we will discuss about how we can make sprint retrospective effective?

1.25 Making Retrospectives Effective

To make sprint retrospective effective get input from everybody, prioritize the list and agree upon few things to try. After this assign actions and follow up. Then agree on token penalty of actions that are incomplete and find a way to make the meeting fun. With this we have completed all the terminologies that are used in Scrum methodology, different meetings, or events. But, who is going to carry out all these activities? Obviously we need to have people. Who are those people? Yes, we need to define roles and responsibilities. We are going to address all these roles and responsibilities in the coming slides.

1.26 Different Roles

Now let’s know about the different roles under scrum. The three main roles are “Product Owner”, “Scrum Master”, and “Developer”. Product owner role is one of the critical roles in collecting requirements from customer or stakeholder and maintaining product backlog. Scrum master role is crucial in applying and maintaining Scrum methodology. The Developers are vital in implementing those product backlogs to deliver value to the customer. In the coming slides we will look into the detail information about each role.

1.27 Product Owner

Let’s now discuss about Product owner role. Product owner role is one of the most critical roles in Scrum. Product Owner is part of the “Scrum Team.” When we say Scrum team, it also includes the Scrum Master and the “Developers.” Product owner provides “direction” to the team. The Product owner is responsible for maximizing the value of the product and the work of the development team. The way it is done may vary widely across organizations, Scrum teams, and individuals. In the next slide we will know more about product owner’s role.

1.28 Product Owner Role

The product owner manages the project’s ROI and risk. To name a few, he or she build business cases for projects and features and will be aware of the risks. Product owner, also take inputs from all stakeholders about what the team should do and translate that into a “backlog.” Apart from this product owner assigns “priority” to items in the backlog and determines the “release plan” with help of the team.

1.29 Product Owner Role

After determining the “release plan” product owner communicates the plan and roadmap to the external stakeholders, participate in the important Scrum meetings like Release and Sprint Planning, Sprint Review. Also be available to the team for clarifying requirements, answering questions, and providing feedback. When we say that the product owner manages the product backlog, the product backlog management includes clearly expressing product backlog items, ordering the items in the product backlog to best achieve goals and missions, ensuring the value of the work the development team performs, ensuring that the product backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next and ensuring the Development Team understands items in the Product Backlog to the level needed. All of the above activities can be carried out either by product owner himself or the development team. But product owner is accountable. Product owner is a single person and is not a group. In the next slide we will understand the role of Scrum Master.

1.30 Scrum Master

Scrum Master is a critical role in the methodology. The Scrum Master helps the team to achieve its goals by serving the team, protecting the team and supporting the team’s use of Scrum. Details of all these points are discussed in the coming slide. Please remember, a project manager can become the Scrum Master, if he or she is working in a matrix organization doing the coordination role. A line manager, one with reporting authority, ideally should NOT become the Scrum Master. When we say matrix organization, it means a blend of functional and projectized organization that is driven by functional and project managers. So, this is the high level role of Scrum Master. In the next two slides, we see as a Scrum Master, what he or she should do or shouldn’t do.

1.31 What Does A Scrum Master Do

Let us first see what the Scrum Master should be doing while following or implementing the Scrum methodology. As we said in the previous slide, the Scrum Master serves the team, protects the team and supports the team’s use of scrum. Serving the team means, facilitating the team’s interactions by coordinating and organizing the Scrum rituals and other meetings. During the meetings there can be lot of hurdles which are preventing the team from moving on. So, the Scrum Master removes the obstacles that are blocking the team. The next one is to protect the team from interference or disturbances from unnecessary influences and resolves conflicts. And lastly, supports the team’s use of Scrum by providing the process guidance, shares best practices, and templates. Also audits that the methodology used by the team correctly or not and in case of emergency may stand in for the product owner in his or her absence. In the next slide we shall further discuss about what Scrum Master shouldn’t do.

1.32 What The Scrum Master Should Not Do

In the previous slide we saw about what scum master does and here comes what he or she should not be doing. As a Scrum Master he or she should not be managing the team or direct the team members. Other than that assigning the tasks, driving, and over ruling the team members are not the role of Scrum Master. Also he or she cannot make decisions on behalf of the team. And most importantly, the Scrum Master should not direct the product strategy which is managed by product owner. In the next slide we will understand the role of Developer.

1.33 The Team Developers

The last role in the Scrum team is of a Developer. Every member of the team in Scrum is called, a “developer” because they ultimately contribute to product development, irrespective of whether they are coding or testing or writing documentation or maintaining databases or source code systems. The team in Scrum should be small. Ideal team size as per the Scrum guide should be seven plus or minus two. The team should be “cross-functional”, i.e., they must have all the skills necessary to complete the work needed. For example, people from testing quality assurance, business analyst, and developer form a team which we call it as developer. Also, the Scrum team needs to be self-managing, i.e., they take responsibility for making decisions – making commitments and making efforts to live up to their commitments. Let us move on to the next slide and know about building a Scrum team.

1.34 Building A Scrum Team

So how does one go about building a Scrum team? It is really no different from any conventional team building theory, with a few minor changes. A Scrum team will need to collaborate internally and externally a lot more than conventional teams. This is driven by the fact that the team is essentially self-managing. There is nobody to tell them what to do and the fact that they need to deliver near releasable code, every iteration or sprint will force them to collaborate a lot more. Therefore, naturally you would look for members who are good at team working and have good communication skills. Another point is that though there certainly is room for specialization, Scrum teams tend to be a lot more homogenous in their skill set. You will need developers willing to lend a hand to testers and you will need testers who can write code to intelligently execute and automate their tests. Last but not the least, you definitely need a highly motivated bunch of people who will make decisions, stand by their decisions and commitments and strive to meet their goals. This essentially means you need to coach the team to stand on their own two feet and then be in a position where you trust them to get the job done. They will definitely promote the right attitude. You also need to allow for the fact that they will not always be successful. So you need to make it “safe” for them to make honest mistakes so long as they are learning from their mistakes and improving as they go along. Just building the team may not be enough, also we should empower them. In the next slide we will discuss about Building empowered teams.

1.35 Building Empowered Teams

The key concept in self-management is “empowerment.” An empowered team is one that acts on its own and with enthusiasm. So empowerment is taking responsibility and ownership and not throwing the rule book out of the window. The second point is working towards the goals or common objectives fairly independently which means not necessarily always bypassing people who say ‘NO’. An empowered team is the one that understands the reasons behind decisions, so that they can apply sound judgment in decision making and it is not about focusing only on the FUN parts of the job while ignoring the tough part. Finally empowerment is all about weighing the impact of decisions on stakeholders and not about unilaterally taking decisions and forcing them on others. In the next slide, we will understand about the role of a manager.

1.36 Role Of A Manager

If you look back at the Scrum life-cycle, you might notice that there is no explicit task assigned to a manager. The Scrum life cycle does not mention the “manager” at all. Indeed the team in Scrum is supposed to be self-managing and there is the ‘Scrum master’ to support them. There is also the Product owner who is supposed to provide guidance about requirements and prioritization. Indeed there is no role called manager that is mentioned in the guidelines at all. For many managers, this might trigger an identity crisis. What does a line manager do in Scrum – do they have a role at all? We will now proceed to the next slide to learn about the new role for the manager.

1.37 A New Role For A Manager

Quite contrary to the belief that Scrum makes the manager redundant, Scrum is so powerful that it liberates the manager from the day-to-day task management and lets him focus on the more strategic and fun parts of their work. In the scrum, a manager could play a more active role in recruiting the right members for their teams, be the mentor or coach for their teams, build the right culture into their teams, help their teams understand the big picture like the business, the strategic vision, etc. Focus on developing the right skills within their teams keeping in mind current and future requirements, administer a good rewards and recognition program to make sure that the team feels motivated to do the right thing, protect the team during tough prioritization calls, deal with issues that cannot be resolved by the team on their own and get escalated to the manager, keep update about the industry, the domain and trends within the business and technology shifts, so that you are geared up to the future and finally, represent the team at any external forums such as quality circles. Think about it. As a manager, what would give you more satisfaction? Doing some of the things listed above or micro-managing the team and taking credit for their success? If you are able to spend the time you saved in day-to-day task management by delegating the teams, you will be able to do a better justice to your job as a manager which will help you in your future career growth. Let us now discuss on some of the specialist roles that you may want to play under Scrum in the next slide.

1.38 Some Specialist Roles You May Want

Scrum refers to each team member as a “developer” and makes no distinctions. Though, here are some specialists roles that you may want to have on your teams, depending upon what your specific challenges and issues are. Let’s look into them one by one. Architect is a highly skilled techie, who is able to provide guidance about the technical roadmap for a product. An architect can take crucial technical decisions about the architecture, framework, model, schema, etc. and then also help the team achieve a correct implementation based on the overall technical vision. A Scrum architect would be expected to be more “hands-on” and would also get involved in things like code or design reviews, etc. Test automation is a critical success factor for a Scrum team. Without a solid backbone of automated tests in place, it is hard to get to the goal of near releasable quality at the end of each Sprint. This is where the automation engineer comes in which we call them as automated testers. These people know the tools and frameworks and can quickly get to automate an existing suite of tests or provide a good architecture and approach for achieving a high level of test automation. They help in moving towards test-driven-development. A configuration manager, build and release manager, etc. – all rolled into one is an excellent asset for a Scrum team. He can maintain the source code repository, automate the processes around code check-in and check-outs, production of builds, integration and automated sanity tests. So in this way he or she can look after the configuration management. With this we have covered definitions used under Scrum, the key events like meetings and the roles of scrum. Whatever so far we discussed, we know that it works very well when the team is co-located. But what happens when the team is distributed. Let’s look into this in the next slide.

1.39 Distributed Scrum Teams

In this slide we will discuss some points about running the Scrum in a distributed environment. Running a distributed team is a challenge. The reason to have a distributed team is often a business decision that is governed by availability of skills and/or cost. So there is no doubt that running a distributed Scrum team is challenging, because, Scrum emphasizes face-to-face communication, cross-functional team, and close collaboration across teams. Some Scrum rituals like daily stand-ups, sprint planning, reviews, etc. occur quite frequently and that would be challenging to organize across time zones. However, distributed Scrum is still better than distributed waterfall. It is still possible to implement Scrum with distributed teams with some best practices to help. What are those best practices? We will answer this in the next slide.

1.40 Best Practices In Distributed Scrum

This slide is about best practices which can be implemented for distributed teams. Before moving on let us understand, first of all, why distributed Scrum is better than distributed waterfall. Now, imagine a situation where the team is spread out halfway across the world with a time zone difference of 12 hours. In this situation, how would you prefer to work? Give the teams large requirement documents and hope that they come up with the right product at the end of six months? OR, build the product incrementally, with frequent checkpoints in the form of working demo of software, something tangible for the customer at the end of every few weeks that allow for correcting any miss-communications? The answer should be self-evident. Three important things need to be kept in mind while working in distributed teams and these are good practices in general irrespective of methodology. The first is applying or tailoring Scrum practices to work effectively in this situation. Second, follow good software engineering practices to keep things tidy. And finally, work hard on people-to-people equations. If we follow these basic principles, we can be assured of success. With this we have come to the end of sharing the knowledge about Scrum methodology at high level. One may be doubting, “Am I the right person to go for Scrum certification?” In the next few slides we will cover about target audience, how to get the certifications, different levels and how Simplilearn can help you in acquiring the same. Let’s first begin with target audience in the next slide. Slide 41 Here is the list of the audiences who can pursue this certification. They are, members of Scrum teams namely Developers, Scrum Masters, Product owners, Managers of Scrum teams, the Teams transitioning or intending to transit to Scrum, and people intending to pursue the Professional Scrum Master certification. Now, that you are aware of the audiences who can attend this course, let us also understand the certifications that are offered in scrum.

1.41 Target Audience

Here is the list of the audiences who can pursue this certification. They are, members of Scrum teams namely Developers, Scrum Masters, Product owners, Managers of Scrum teams, the Teams transitioning or intending to transit to Scrum, and people intending to pursue the Professional Scrum Master certification. Now, that you are aware of the audiences who can attend this course, let us also understand the certifications that are offered in scrum.

1.42 Certifications Overview

Following certifications are available in Scrum. Depending on your role, you can opt for certified Scrum Master whom we also call as CSM, certified product owner or CSPO, and certified Scrum developer or CSD. One can also become certified Scrum professional which is CSP. But before becoming a CSP, applicants must be CSMs, CSPOs, or CSDs. To get more details on this please log on to www.scrum.org and or www.scrumalliance.org. So, how can this certification be achieved? Participants need to take training from a Certified Scrum Trainer and clear online test after the training program is over. To know more about training workshop, just visit the next slide.

1.43 Scrum With Simplilearn

Here you are! Simplilearn provides 2-days workshop on Scrum concepts and certification program. It is conducted by an experienced person who has used the methodology for years and has facilitated many training programs globally and has a rich project management experience. The training provides activities based on practical and live examples so that you will not forget about the basic concepts. For future reference, Simplilearn provides additional material with online access privileges.

1.44 Contact Us for More Information

With this we have come to end of introductory part of Scrum @ High Level. Thank you for participating. Hope you enjoyed the session. For more information please contact support@simplilearn.com or log on to www.simplilearn.com Well, what are you waiting for? Please drop a mail to support@simplilearn.com See You Soon.

Find our Certified ScrumMaster® (CSM) Classroom training classes in top cities:

Name Date Place
Certified ScrumMaster® (CSM) 3 Oct-4 Oct, 2020, Weekend batch Your City View Details
Certified ScrumMaster® (CSM) 3 Oct-4 Oct, 2020, Weekend batch Dallas View Details
Certified ScrumMaster® (CSM) 13 Oct-14 Oct, 2020, Weekdays batch New York City View Details
  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*