Agile Scrum Introduction Tutorial

1.1 Introduction to Agile and Scrum

Welcome to Simplilearn’s Agile-Scrum training program. In this program you will learn about the basics of Agile software development and then cover the Scrum methodology in-depth. Agile software development has been practiced for a long time. It started in the early to mid-nineties and had many popular flavors, including DSDM, Scrum, Extreme programming, etc. The agile manifesto, which was signed in Feb 2001, brought together the leaders of several of these methodologies under a common platform to define the principles and philosophy underlying incremental and iterative development.

1.2 Agenda

This Chapter will help introduce the participants to the world of Agile software development with a Scrum flavor. In this lesson, we shall start off with understanding why Agile methodologies are becoming popular. We shall explore some of the issues from traditional software development practices and how Agile helps to address them. We shall look at the history of Agile software development and the evolution of the Agile manifesto. The Agile manifesto is supplemented by 12 principles of Agile software development. We shall then understand the Agile project management framework, which provides a basis for defining the Agile project life-cycles. We shall then briefly introduce Scrum, which is one of the most popular Agile methodologies prevalent in the industry. We shall also briefly talk about the certifications in Agile and Scrum. Let us get introduced to this course in the next slide.

1.3 Why Agile

There is no doubt that Agile methodologies are highly pervasive in the software development industry and that their popularity is growing rapidly. Some data points are mentioned here. Project Management Institute research indicates that the use of Agile methodologies had tripled within a two and half year period between May 2008 to December 2011. 74% of software professionals surveyed had used Agile at some point in their career, and 55% of them were using Agile for 2 years or more. Gartner research predicts that 80% of all software development projects will use Agile by December 2012. It is very clear that Agile is here to stay. You may like or dislike the methodology, but ignoring this trend is not an option. After understanding the required details of agile, let us now move on to the next slide where we will look into the objectives of this course.

1.4 Course Objectives

This course provides a background and philosophy behind Agile methodologies and introduces many of the commonly used Agile methodologies. It goes in-depth into Scrum and provides detailed guidance about all of the aspects of Scrum. It provides details about various scrum roles including the scrum master, product owner and development team roles. It helps you to learn about ceremonies, , including the Daily Scrum, Sprint and Release planning, Sprint review and Sprint retrospective. It also talks about the artifacts including the Product and spring backlogs, Deliverables and Definition of Done. Next, we will also discuss on the best practices around Release and Sprint planning, including estimation and engineering best practices that help during execution. At the same time it provides a proper guidance on how to monitor and track a Scrum project and appropriate metrics and indicators that may be used. This course also offers few advanced topics such as applying Scrum to distributed teams, on large and complex systems, and issues observed while transitioning a team to Scrum. Let us now look at the objectives. On completing the course, the participants should be able to: -Embrace the philosophy of Agile as specified in the Agile manifesto and cultivate an in-depth understanding of Scrum methodology. -Apply Scrum effectively in their organizations and potentially evangelize the methodology. -Appear for any test related to Scrum including those for certifications, such as the CSM, PSM, CSD, PSD, CSPO, PSPO, CSP, etc. - Let us now look at the target audience for this program in the next slide

1.5 Target audience

This program will be valuable to the following categories of participants. -All individual contributor roles, such as Developers, Testers, Architects, etc. who are currently working or likely to work on a Scrum project in the near future. -Project managers or Scrum masters who have the mandate to steer a Scrum team. -Product owner, business analysts or any customer representative on Scrum teams. -Senior and executive management, process coaches and members of the SEPG, QMG or corporate PMO who might be in a position to manage or govern Scrum projects. For the course to be beneficial the participants must meet the following pre-requisites: -At least 3 years of practical experience of working on software development projects. -An understanding of at least one software development methodology (even traditional/waterfall will do). -Participants must have an open mind to learn a different technique or methodologies. We will now proceed to understand Traditional development in the next slide.

1.6 Traditional Development

Let us step back for a moment and look at how traditional software development methodologies (often termed “waterfall” or Software Development Life-cycle - SDLC) work. It follows a fairly regular series of steps from Analysis to design to code to test and then deployment. There is nothing wrong with this life-cycle. Indeed it is a very logical sequence of steps that should lead to the intended output. The only issue with this methodology is that it assumes predictability. Normal software development projects are not predictable. They are prone to requirement changes multiple times during the cycle, they may require the design to be changed multiple times in response to changes in the technical environment, etc. The traditional SDLC makes it very hard to recover from an unforeseen event. For example, if a requirement change is received during the testing cycle, the entire series of steps from Analysis to code need to be repeated, which may lead to a ripple effect on the other features. In the next slide, we will discuss about the Problems with traditional software development.

1.7 Problems with traditional software development

The inherent inflexibility of traditional software development leads to many of the symptoms that we see here. You may be familiar with many of these on your projects and perhaps may add a few more of your own too. Most Product Managers would complain that it takes forever for an “idea” to translate into a working feature in a released product. In other words, “time-to-market” is very high. This can be very costly in a fast-paced and dynamic business environment. The return-on-investment on features is very low as a result of the high cost of software development and lack of customer orientation. The ability to respond to changes is low. The productivity of teams working in this mode is low as it does not utilize the resources evenly across the various stages of the life-cycle. There is high potential for re-work based on changes in requirements, design or code and general perception of quality delivered to the customer is bad. There is a high incidence of failure on software development projects. The project failure rate has become 68%. Studies carried out by the Standish group indicate that 24% of the software projects studied were complete failures and never saw the light of day. Another 44% projects came in late or over-budget or did not deliver the agreed upon features. Whichever way you look at these statistics, it paints a pretty dismal picture of our industry and our ability to deliver customer value.

1.8 Usage of features in a system

One of the most unfortunate consequences of traditional SDLC is that it promotes inefficient use of resources and “over-engineered” solutions. Another Standish group study indicates that 45% of features in a typical system are NEVER used and another 19% are used very rarely. This is a colossal waste of resources, as they ended up building features which obviously no customer cares about. One of the biggest advantages of Agile methodologies is that it forces teams to be disciplined about the sequence in which they build the features. By always focusing on a small subset of features to be worked on, it leads to clearer insight into the priority of these features. This is what ultimately results in value being delivered to the customers quicker, because they get their highest priorities addressed quicker. Let’s go over to the next slide and learn how to make a new approach.

1.9 Makings of a new approach

Due to the inherent limitations of traditional software development life-cycle, people tried to come up with different approaches that might help them become more flexible and adaptable. Prominent among them were Rapid application development and Spiral models. The idea was to make the development life-cycle incremental and iterative. Incremental means working in small chunks at a time, i.e. work on few requirements at a time, turn it into working software and only then start working on the next set of requirements. Iterative means taking feedback periodically and incorporating the lessons from previous iterations while planning future work. The term Agile itself came into being when the Agile Alliance was formed and the Agile manifesto was signed in February 2001. This brought together 17 senior software professionals all of whom were looking to overcome the limitations of traditional development by using incremental and iterative approaches. So remember that any methodology that is incremental and iterative can be called Agile. Many of the principles from Lean manufacturing methods find an echo in Agile development, but it is important to understand that Agile is not the same as Lean. For example, Lean does not necessarily talk about iterations whereas Agile is all about being iterative.

1.10 Agile Manifesto

As discussed earlier, Agile processes are lightweight and non-prescriptive. There are very few immutable principles that cannot be altered. The Agile manifesto and principles are few of those cores, immutable principles and hence we must pay attention to understanding these well. This also forms part of Knowledge and Skills (Level-1) in the examination content outline, so one must expect questions about the Agile manifesto and principles in the examination. Hence we recommend almost memorizing and fully internalizing these principles. The core of the Agile manifesto specifies, what Agile values more and what it values less. For example, Agile values individuals and interactions over processes and tools. It values working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. It DOES NOT say that documentation, processes, tools, negotiation, following a plan is NOT important. It simply states that individuals, interactions, working software, customer collaboration and responding to change are MORE important. As we discuss the Agile principles on the next slide, we shall try to explain these more.

1.11 Principles behind the Agile Manifesto

To further amplify the message of the Agile manifesto, 12 basic principles were stated. Let us try to understand and absorb the 12 principles of Agile development. 1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Agile methodologies try to give the customer early delivery of working software so that he can start realizing value faster. 2.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Being able to accept changing requirements at any stage in a project enhances the customer’s competitive advantage. Hence Agile processes must learn to handle this change (no matter how late it is made known to the team). 3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Agile teams must deliver “working software” – not merely prototypes. The frequency of delivery should be from 2 weeks to 2 months - sooner the better. 4.Business people and developers must work together daily throughout the project. The business users of the system and the developers of the system must have very close (almost real-time) collaboration throughout the project. 5.Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. Agile methodologies place a great emphasis on the team. Managers need to spend more of their time in building the right team and enabling them with the supporting environment for doing their work. 6.The most effective and efficient way of conveying information to and within a development team is face-to-face conversation. Though other means of communication (email, IM, teleconferences, etc.) exist and should be used, nothing comes close to face-to-face conversation in terms of the richness of the interaction. Therefore, you must prefer to communicate face-to-face as far as possible. 7.Working software is the primary measure of progress. The only way to really find out if you are making progress on a software development project is to have working software to show for it. Documentation, power point, status reports may provide some insight – but on their own they are useless unless backed up by the working software. 8.Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. Agile is not about running as fast as you can. It is not about running a 100 meter sprint. It is actually about running at a speed that will allow you to run a marathon. If the pace is not sustainable, you won’t last the distance.9.Continuous attention to technical excellence and good design enhances agility. A common misconception about Agile is that it does not allow time for design and technical approach. Agile methods actually emphasize continuous – rather than one time, up-front design. 10.Simplicity – the art of maximizing the work not done – is essential. Simplicity means that the team must implement the simplest solution to the customer’s problem. The ”work not done” stated here implies that one must avoid over-engineering or anything that the customer does not care about. 11.The best architectures, requirements and designs emerge from self-organizing teams. Self-organization is an important Agile principle. When a team is empowered and have autonomy to take decisions, they are more likely to take the correct technical decisions. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. This principle reflects the iterative nature of Agile development. At the end of the iteration, the team must pause to learn the lessons from the past iteration, and decide how they want to adjust their behavior before moving on to the next iteration. We will now go through the Authors of the Agile manifesto, in the next slide.

1.13 Authors of the Agile Manifesto

The authors of the Agile manifesto include thought leaders from the software industry and founders of many of the well-known Agile methodologies. Kent Beck is the founder of Extreme Programming. Alistair Cockburn (pronounced Co-burn) founded the Crystal family of methodologies. Ken Schwaber, Jeff Sutherland and Mike Beedle founded Scrum. Arie Van Bennekum has worked extensively on Rapid Application Development and DSDM methodologies. Ward Cunningham developed the world’s first wiki and is a pioneer in design patterns and extreme programming. Martin Fowler is Chief Scientist with Thought works, which are early adopter and pioneer in Agile methodologies. Jim Highsmith is the primary developer of Adaptive Software Development. Andrew Hunt is a partner in Pragmatic Programmers and an author and consultant in Agile methodologies. Ron Jeffries is a consultant and proprietor of and the first extreme programming coach. Joe Kern is a consultant and author on Agile methodologies and has worked closely with Jeff DeLuca and Peter Coad on Feature-Driven-Development. Brian Marick is a programmer and a software testing consultant and a thought leader on the subject of Agile testing. Robert C.Martin is a consultant on Extreme programming and Agile and author of several best-selling books about design patterns. Dave Thomas is a well-known consultant in Agile methodologies. James Grenning is a consultant on Agile and one of the pioneers and thought leaders in the practice of test-driven-development. Steve Mellor is a computer scientist and the developer of the Shlaer-Mellor method of object-oriented analysis and design. The common thread among these leaders is the belief that iterative and incremental methodologies lead to better projects. The Agile manifesto is thus the distilled form of Agile principles. Let us move on to the next slide which contains a diagram and learn about Agile Project Management.

1.14 Agile Project Management

The “triple constraints “or the iron triangle on traditional projects comprises of Scope, Cost and Time. We call it the iron triangle because it has a very rigid way of looking at the parameters that govern the success of a project. The Agile triangle inverts this by keeping customer value as the ultimate goal. Quality is a key contributor to the value creation process and the creation of value has to be within certain constraints. The constraints are expressed in terms of Scope, Cost or Schedule. So a project must be driven by Scope (must have a certain set of features) or schedule (must have a release by a certain date) or Cost (should not exceed a certain budget). However, as we work within the constraints that govern the project plan, we need to constantly and relentlessly focus on delivering the maximum customer value and maintain good intrinsic quality – the foundation on which customer value is delivered. Now, we will look into the figure in the next slide and discuss on Agile Project Management Life-cycle.

1.15 Agile Project Management Life cycle

The common processes within a project can be classified within the 5 process groups as follows. -Initiating (Typically occurs only once at the beginning of a project or phase) -Planning (Agile planning is iterative, hence it occurs at the beginning of the project as well as the beginning of each iteration) -Execution (Agile executes through iterations, so each iteration will see execution activity peaking somewhere in the middle) -Controlling (Controlling is about checking progress against plan and taking steps to bring things back on track – it would happen hand-in-hand with execution) -Closing (Bring projects to orderly closure – would typically happen only once at the end of a project or phase). - -In Agile Project Management, Planning is an iterative component of the project lifecycle. -In that figure, we can look at the repeated sets of green shading as planning occur throughout the project lifecycle. -In the next slide we will talk about Agile Project Management Framework.

1.16 Agile Project Management Framework

The Agile project management framework first described by Jim Highsmith in the book “Agile project management – creating innovative products). It depicts a series of steps that take you from an initial vision of the product to the final product. It is quite analogous to the process groups within the PMBOK. Typically, Envision and Close will occur only once during a project. However, the Speculate, Explore and Adapt phases will repeat iteratively for as long as it takes to create a complete product with adequate value for the customer. For instance, the Speculate phase would result into the development of a tentative features list and a release plan. During the explore phase, some completed features would be delivered. At the adapt stage, a finished product would get delivered to the customer after verification. Next, we will cover APM Framework and look into these stages in more detail.

1.17 APM Framework

The various steps in the Agile project management framework and the activities involved in each phase are as follows. -Envision (Creating a high level vision for the project. The vision is the desired end goal. Along with the vision, this stage also aims to develop a high level scope for the project, identify the stakeholders or community for the project and explains how the team will work together to achieve the vision. -Speculate (Creating a high level roadmap for the project, based on the available information. Typically a release plan and a tentative feature list will emerge from this phase). The release plan will provide high level milestones based on division of features into several iterations or short duration time-boxes. It is important to understand that this is a “tentative” plan based on the current understanding. That is why it is called “Speculate” as opposed to “Plan”. -Explore (This is where the team will start creating and delivering the features, exploring various options and innovating as best as they can) -Adapt (The team will constantly adapt and change their plan based on the feedback they receive about the completed features and their experiences from developing them) -Close (After the team has generated sufficient value – or whenever the customer has had enough, the project will close and the features delivered will be finalized). - -Let us proceed to the next slide and understand what Scrum is all about.

1.18 What is Scrum

At this point, let us introduce the Scrum methodology. It is an Agile methodology with specific practices built around small, self-managed teams working towards a software development project. It is a methodology for software development that adheres to Agile principles of iterative and incremental development. The methodology was founded by Ken Schwaber, Jeff Sutherland and Mike Beedle. The authentic sources for getting Scrum guidelines and white papers are the Scrum Alliance website ( or Ken Schwaber’s website ( The term Scrum itself originates from the sport of rugby, where the Scrum is the team huddle just before the beginning of a new “play”. The daily stand-up meetings (one of the Scrum rituals) are sometimes referred to as the Daily Scrums. Many Scrum terms are borrowed from rugby. Scrum is one of the most popular among the various Agile methodologies in vogue. There is significant demand in the industry for Scrum aware and Scrum certified professionals. Let us now proceed to understand some of the certifications out there for Scrum and Agile professionals. Now, we will gain an understanding about Certified Scrum Master.

1.19 Certified Scrum Master

The CSM certification is offered by the Scrum Alliance (website: The Scrum Alliance offers certifications for Scrum Masters as well as Product Owners. It further also offers accreditations like Certified Scrum Professional (aimed at practitioners) and Certified Scrum Trainer (aimed at Scrum trainers). For becoming a Certified Scrum Master, you first need to attend a course conducted by a Certified Scrum Trainer. The application has to be submitted through a CST. After completing the course and the application process, the aspirants must clear an online evaluation. The certification is valid for 2 years, after which it must be renewed by paying a renewal fee. More details are available on the Scrum Alliance website that is; Let us now talk about Professional Scrum Master in the next slide.

1.20 PMI ACP

The Project Management Institute offers the PMI Agile Certified Professional certification. Unlike the CSM and PSM certifications, this is not a Scrum certification, but a generic certification that tests the aspirants on their competencies on a wide variety of Agile methodologies. The ACP is knowledge as well as experience based certification, so the pre-requisites for the certification are 12 months of general project as well as 8 months of agile project experience. You also need to go through at least 21 hours of education in Agile methodologies before you can schedule an exam. The exam itself consists of 120 multiple choice questions to be solved over a 3 hour period. After passing the examination, you acquire the PMI-ACP certification. The process of acquiring the certification is to submit online application after fulfilling pre-requisites, after approval of application, schedule and pass the exam. Like the other PMI certifications, the ACP certification is valid for 3 years, after which it needs to be renewed. We will learn more about this tutorial in the next slide.

1.21 About this tutorial

Before we proceed further, let us take a quick look at the contents of this tutorial. In lesson-2, we look at the various Agile methodologies out there, including Extreme Programming, Crystal, Feature-Driven-Development, DSDM, AUP, etc. and also learn about Scrum. In lesson-3, we look at the various “roles” within a Scrum team. Specifically, we look at the Product Owner, the Scrum Master and the Developer roles. We also consider some of the conventional roles on projects like Manager, Architect, etc. and discuss how they might play out on a Scrum project. In lesson-4, we look into the various rituals or ceremonies that occur on a Scrum project – including Sprint and release planning, the Daily Scrum, Sprint Review and retrospectives. All these rituals have an important place in going through a Scrum project. In lesson-5, we focus on the various artifacts within Scrum. Here we focus on the backlog and the requirements that get generated on a Scrum project. In lessonr-6, we shall focus on some Scrum best practices. These are important to ensure that the project stays on track and stays true to the Scrum goals of working software and near releasable quality at the end of the iteration. We also look at some testing and QA related best practices. In lesson-7, we pay a little closer attention to the Planning process within Scrum. This is about the principles of planning and keeping the plan flexible. In lesson-8, we look at the process of estimation on Scrum projects. We look at the techniques that are commonly used to get to a predictable and reliable estimate. In lesson-9, we look at the monitoring of Scrum projects. Monitoring is about making the progress or lack of progress visible to the team so that they can take the corrective actions necessary. In lesson-10, we look at some advanced concepts related to the application of Scrum. We look at executing large and complex projects using Scrum, the process of selling Scrum to the customer and also about transitioning and existing team to Scrum. As of now, we have covered many important topics of agile and scrum. Now, try to answer few questions about those topics.

1.22 Quiz

Let us quickly test our understanding of this Chapter through this quiz. Which of the following best practices describes the essential characteristic(s) that make any methodology Agile? A-V-model B-Pragmatic and Predictable C-Iterative and Incremental D-Rapid prototyping Answer is C: Agile methodologies are necessarily incremental and iterative. Unless they incorporate both these, they will not be aligned in spirit with the agile manifesto and principles. Which of the following is NOT an assertion of the Agile manifesto? A-It values following a plan over responding to change B-It values working software over comprehensive documentation C-It values customer collaboration over contract negotiation D-It values individuals and interactions over processes and tools Answer is A: The Agile manifesto says responding to change is more valuable than following a plan. According to Agile principles, what should be the speed of development? A-Speed that can be sustained indefinitely B-Slow, so that quality can be built in C-As fast as possible – because Agile is all about speed D-Constantly increasing pace Answer is A: The Agile principles clearly state that the Agile processes should promote sustainable pace. State the correct sequence of the phases in the APM framework model? A-Envision, Speculate, Adapt, Explore, Close B-Envision, Speculate, Explore, Adapt, Close C-Envision, Explore, Speculate, Adapt, Close D-Speculate, Envision, Explore, Adapt, Close Answer is B: The correct sequence is Envision, Speculate, Explore, Adapt and Close. With this we have come to the end of our introductory lesson. If you are clear about this lesson on Agile-Scrum, let’s move on to the other lessons in which will talk more about this course. The next part covers lesson two of this course which is on Agile Methodologies. Happy learning!

  • 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*
Phone Number*
Job Title*