Agile & Scrum

Amrita

Outline

Origin of Scrum History of Scrum Scrum has been used in/for What is Scrum Why Scrum Scrum Sprint Scrum Practices 1. Roles 2. Ceremonies 3. Artifacts Why Scrum works Pros and Cons Agile Scrum In Depth Online Guide Questions
2

Origins of Scrum

Origins of Scrum

The New New Product Development Game in Harvard Business Review by Hirotaka Takeuchi and Ikujiro Nonaka, 1986. The relay race approach to product developmentmay conflict with the goals of maximum speed and flexibility. Instead a holistic or rugby approachwhere a team tries to go the distance as a unit, passing the ball back and forthmay better serve todays competitive requirements. Wicked Problems, Righteous Solutions by DeGrace and Stahl, 1990. First mention of Scrum in a software context
4

Were losing the relay race

The relay race approach to product developmentmay conflict with the goals of maximum speed and flexibility. Instead a holistic or rugby approachwhere a team tries to go the distance as a unit, passing the ball back and forthmay better serve todays competitive requirements. Hirotaka Takeuchi and Ikujiro Nonaka, The
New New Product Development Game, Harvard Business Review, January 1986.

Were losing the relay race !!

Origins of Scrum

Jeff Sutherland Initial Scrums at Easel Corp in 1993 IDX and nearly 600 people doing Scrum Not just for trivial projects
FDA-approved, life-critical software for x-rays and MRIs

Ken Schwaber ADM Initial definitions of Scrum at OOPSLA 96 with Sutherland Mike Beedle Scrum patterns in PLOPD4
7

History

History: A Timeline

Scrum has been used by:

Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce
10

Scrum has been used for

Commercial software Video game development FDA-approved, life-critical systems Satellite-control software Websites

In-house development
Contract development Fixed-price projects Financial applications ISO 9001-certified applications Embedded systems

Handheld software
Mobile phones Network switching applications

24x7 systems with 99.999% uptime requirements

The Joint Strike Fighter

ISV applications
Some of the largest applications in use
11

What is Scrum

Figure 1
12

What is Scrum
Figure 1 shows how Scrum Agilists treat requirements like a prioritized stack, pulling just enough work off the stack for the current iteration (in Scrum iterations/sprints are often 30-days long, although this can vary). At the end of the iteration the system is rolled out to the stakeholders to verify that the work that the team promised to do at the beginning of the iteration was in fact accomplished.

13

What is Scrum

14

Scrum is an Agile Process

15

Scrum is an Agile Process

16

What is Scrum: Summary

Scrum in 100 words

Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
17

What is Scrum: Characteristics

One of the agile processes Self-organizing teams Product progresses in a series of 2 to 4 week long sprints Requirements are captured as items in a list of product backlog No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects

18

Why Scrum

Figure 2

Traditional SDLC

19

Why Scrum

Traditional Software Development Lifecycle

Requirements Gathering and Analysis Design Implementation Testing Delivery

Output of one stage serves as input for the succeeding stage

20

Why Scrum: Problems with Traditional SDLC

Assumption
Each stage produces a predictable and defined output Application of the process results in repeatable outputs

Results
Loss of control Surprises Incomplete or wrong products
21

Why Scrum : Scrum Solutions to SDLC Problems

Major approaches to controlling processes

Defined process control Empirical process control

Defined process control

Well defined set of inputs Repeatable outputs upon completion
22

Why Scrum : Scrum Solutions to SDLC Problems

Empirical process control

Expects the unexpected Provides and exercises control through frequent inspection and adaptation Imperfectly defined processes that generate unpredictable and unrepeatable results

23

Scrum Solutions to SDLC Problems : Empirical Process Control

Scrums foundation in empirical process control is important because its model that fits the realities of creating software. Consider the following succinct definition from Wikipedias short entry on the topic: The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. Wikipedia Empirical process (process control model)
24

Scrum Sprint

25

Scrum Sprint
Figure 3
24 hours Daily Scrum Meeting Sprint Backlog tasks expanded by team 30 days

Sprint Backlog

Product Backlog As prioritized by Product Owner

Potentially Shippable Product Increment

Source: Adapted from a presentation on Scrum [2] that has Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

26

Scrum Sprint

http://www.youtube.com/watch?v=Wxiu E-1ujCM&feature=related

27

Scrum Sprint
A sprint is the basic unit of development in Scrum. Sprints last between one week and one month and are a "timeboxed" (i.e. restricted to a specific duration) effort of a constant length. Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting,where the progress is reviewed and lessons for the next sprint are identified. During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is a prioritized list of requirements. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. 28 After a sprint is completed, the team demonstrates how to use the software.

Scrum Sprint

Sprint
Lasts for about 7-30 days Implement the top priorities in the Project Backlog called as the Sprint Backlog Sprint estimates updated as tasks are completed or new tasks crop up Potentially shippable product increment

29

Scrum Framework/Practices

30

Scrum Framework

31

Scrum Practice 1- Roles

Scrum contains sets of predefined roles.Scrum teams consist of three core roles and a range of ancillary rolescore roles are often referred to as pigs and ancillary roles as chickens. Core roles The core roles in Scrum teams are those committed to the project in the Scrum processthey are the ones producing the product(objective of the project). Scrum has three fundamental roles: Product Owner, ScrumMaster and Team Member.

Ancillary roles The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum processbut nonetheless, they must be taken into account.

32

Scrum Practice 1- Roles ( Chicken & Pigs)

The Classic Story of the Pig and Chicken

Figure 4

http://www.implementingscrum.com/

33

Scrum Practice 1- Roles ( Chicken & Pigs)

The Classic Story of the Pig and Chicken

The basic fable runs:

A Pig and a Chicken are walking down the road. The Chicken says, "Hey Pig, I was thinking we should open a restaurant!". Pig replies, "Hm, maybe, what would we call it?". The Chicken responds, "How about 'ham-n-eggs'?". The Pig thinks for a moment and says, "No thanks. I'd be committed, but you'd only be involved!

Sometimes, the story is presented as a riddle:

Question: In a bacon-and-egg breakfast, what's the difference between the Chicken and the Pig? Answer: The Chicken is involved, but the Pig is committed!
34

Scrum Practice 1- Roles ( Chicken & Pigs)

Pig roles The Pigs are the ones committed to the project in the Scrum processthey are the ones with their bacon on the line and performing the actual work of the project. Scrum Master (or Facilitator) Scrum is facilitated by a Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The Scrum Master is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Masters role is to protect the team and keep them focused on the tasks in hand. Scrum Team The team has the responsibility to deliver the product. A team is typically made up of 59 people with cross-functional skills who do the actual work (design, develop, test, technical communication, etc.). Product Owner The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the right things from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog. A Product Owner can be a 35 member of the Scrum Team but cannot be a ScrumMaster.

Scrum Practice 1- Roles ( Chicken & Pigs)

Chicken roles Chicken roles are not part of the actual Scrum process, but must be taken into account. They are people for whom the software is being built. Stakeholders (customers, vendors) These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews. Managers People who will set up the environment for the product development organizations.

Figure 5

36

Scrum Practice 1- Core Roles

Scrum Master
Scrum is facilitated by a Scrum Master, sometimes written as ScrumMaster, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster manages the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner.

The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team. A key part of the Scrum Masters role is to protect the Development Team and keep it focused on the tasks at hand.
37

Scrum Practice 1- Core Roles

Scrum Master Interface between the management and the scrum team Typically an experienced engineer Responsible for removing impediments that stall the progress of Scrum Team Members Should be able to make quick decisions based on incomplete data The role has also been referred to as a servantleader to reinforce these dual perspectives.
38

Scrum Practice 1- Core Roles

Product
The

Owner

Product Owner represents the voice of the customer and is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. the Product Owner has the most authority of the three roles, its also the role with the most responsibility.
Because

39

Scrum Practice 1- Core Roles

Product Owner
Sole owner of the product backlog Changes to the product backlog have to be approved by the product owner Mostly Business Analyst ( In some cases Project Managers or Technical Leads)

40

Scrum Practice 1- Core Roles

Product Owner
Assure team is pursuing a common vision Establish priorities to track business value Act as the customer for developer questions Work with product management to plan releases Plan, elaborate and accept user stories and iterations Technical: understand and prioritize refactoring and infrastructure

Dean Leffingwell, Scaling Software Agility

41

Scrum Practice 1- Core Roles

Development Team/Scrum Team

In Scrum methodology, the Development Team is responsible for completing work. For software projects, a typical team includes a mix of software engineers, architects, programmers, systems analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owners situation, that freedom is accompanied by a responsibility to meet the goals of the sprint. The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 39 people with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs).
42

Scrum Practice 1- Core Roles

Development Team/Scrum Team

43

Scrum Practice 1- Core Roles

Development/Scrum Team
Cross Functional Designers, Testers, Systems Analysts etc Recommended Team Size 5 - 10

44

Scrum Practice 1- Ancillary roles

Ancillary roles Stakeholders (customers, vendors) These are the people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews. Managers People who control the environment.

45

Scrum Ceremonies/Meetings

Sprint Retrospective Meeting

46

Scrum Practice Sprint Planning Meeting

Sprint planning meeting

At the beginning of the sprint cycle (every 730 days), a Sprint planning meeting is held. Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team Identify and communicate how much of the work is likely to be done during the current sprint Eight-hour time limit (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog

47

Scrum Practice Sprint Planning Meeting

Figure 5

48

Scrum Practice Sprint Planning Meeting

49

Scrum Practice Sprint Planning Meeting

50

Daily Scrum Meeting

Scrum Practice - Daily Scrum Meeting

Each day during the sprint, a project status meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines: The meeting starts precisely on time. All are welcome, but normally only the core roles speak The meeting length is set (timeboxed) to 15 minutes The meeting should happen at the same location and same time every day During the meeting, each team member answers three questions: What have you done since yesterday? What are you planning to do today? Any impediments/stumbling blocks? It is the role of the Scrum Master to facilitate resolution of these impediments, although the resolution should occur outside the Daily Scrum itself to keep it under 15 minutes.

http://www.youtube.com/watch?v=q_R9wQY4G5I

51

Scrum Practice - Daily Scrum Meeting

52

Scrum Practice Scrum of Scrums

Scrum of Scrums Each day normally after the Daily Scrum. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. A designated person from each team attends. The agenda will be the same as the Daily Scrum, plus the following four questions: What has your team done since we last met? What will your team do before we meet again? Is anything slowing your team down or getting in their way? Are you about to put something in another teams way?
53

Scrum Practice - Daily Scrum Meeting

Stand Up Daily Scrum

Figure 6

54

Scrum Practice - Daily Scrum Meeting

Scrum Board

Figure 7

55

Scrum Ceremonies/Meetings Contd.

At

the end of a sprint cycle, two meetings are held: the Sprint Review Meeting and the Sprint Retrospective

56

Scrum Practice Sprint Review

57

Scrum Practice Sprint Review

Sprint Review
Lasts for about 4 hours Provides feedback to the management Provides feedback to the next Sprint

58

Scrum Practice Sprint Retrospective

Sprint retrospective

All team members reflect on the past sprint Make continuous process improvements Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Three-hour time limit

59

Scrum Practice Sprint Retrospective

60

Scrum Artifacts
1. Product Backlog (User Story) 2. Sprint Backlog 3. Sprint Burndown Chart 4. Sprint Task Board

61

Scrum Practice Product Backlog

During the Sprint Planning Meeting the Product Owner prioritizes the items in the Product Backlog and describes them to the team. The team then determines which items they can complete during the coming Sprint. The team then moves items from the Product Backlog to the Sprint Backlog. In doing they expand each Product Backlog item into one or more Sprint Backlog tasks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritized Product Backlog list and draws a line after the lowest of the high priority items they feel they can complete. In practice it is not unusual to see a team select, for example, the top five items and then two items from lower on the list but that are associated with the initial five. Product backlog items can be technical tasks ("Refactor the Login class to throw an exception") or more user-centric ("Allow undo on the setup screen"). The Product Backlog can be maintained in an Excel spreadsheet.

62

Scrum Practice Product Backlog

An example from a real project is shown in Figure 5. This Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by the Product Owner. Estimates are useful only for assignments of tasks into the various sprints.

63

Scrum Practice SAMPLE Product Backlog with User Stories

http://www.mountaingoatsoftware.com/scrum/product-backlog-example/ Figure 8
64

Scrum Practice Sprint Backlog

65

Scrum Practice 9 SAMPLE Sprint Backlog

Figure 9

66

Scrum Practice 9 SAMPLE Sprint Backlog

Figure 10

http://www.mountaingoatsoftware.com/scrum/sprint-backlog/
67

Scrum Practice Sprint Burn Down Chart

68

Scrum Practice Sprint Burn Down Chart

Figure 11

69

Scrum Practice Sprint Task Chart

Figure 12 (Tasks)

70

Scrum Practice Sprint Burn Down Chart

Figure 13 (Hours of Effort and Days)

71

Scrum Practice Sprint Burn Down Chart

In Figure 13 the estimated work remaining in the sprint is calculated daily and graphed, resulting in a Sprint Burndown Chart. The vertical axis displays the hours of effort remaining for the Sprint. The horizontal axis displays the days of the Sprint. The burndown is supposed to be shown by the line of descent from the start of the Sprint with the starting hours, down to the end of the Sprint with no hours remaining. The team does its best to pull the right amount of work into the sprint but sometimes too much or too little work is pulled in during the Sprint Planning Meeting in this case the team needs to add or remove tasks. In the above sprint burndown chart you can see that the team had pulled in too much work initially and still had nearly 600 hours to go on 5/16/02. In this case the Product Owner was consulted and it was agreed to remove some work from the sprint, which resulted in the big drop on the chart between 5/16/02 (619 hours) and 5/17/02. From there the team made good consistent progress and finished the sprint successfully. http://www.mountaingoatsoftware.com/scrum/sprint-backlog
72

Scrum Practice User Story

A feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. The structure of a story is: "As a <user type> I want to <do some action> so that <desired result>" This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand. Example: As a wiki user I want a tools menu on the edit screen so that I can easily apply font formatting. A story is an independent, negotiable,valuable,estimatable, small, testable requirement ("INVEST Acronym").

Despite being independent i.e. they have no direct dependencies with other requirements, stories may be clustered into epics when represented on a product roadmap or further down in the backlog.
73

Scrum Practice User Story

EXAMPLES:

1.As a bank customer I can change my PIN. 2.As a student, I can find my grades online so that I dont have to wait until the next day to know whether I passed. 1.As a book shopper, I can read reviews of a selected book to help me decide whether to buy it. 1.As an author, I want the spell checker to ignore words with numbers so that only truly misspelled words are indicated.

74

Scrum Practice User Story

As a <user type> I want to <achieve a goal> So that I can <get some value>

75

Scrum Practices - Summary

Figure 14
24 hours Daily Scrum Meeting Sprint Backlog tasks expanded by team 30 days

Sprint Backlog

Product Backlog As prioritized by Product Owner

Potentially Shippable Product Increment

Source: Adapted from a presentation on Scrum [2] that has Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

76

Why Scrum Works

Most of the defined model assumptions are removed Constant feedback Focused on What can be done instead of Why it cant be done

77

Pros/Cons of Scrum

78

The Agile Software Development Revisited

Agile Software Development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self organizing, cross functional teams. Agile Manifesto In February 2001, 17 software developers met at the Snowbird, Utah Resort, to discuss lightweight development methods and as result published the Manifesto for Agile Software Development to define the approach now known as Agile Software Development. http://www.agilemanifesto.org/

Agile Alliance Some of the manifesto's authors formed the Agile Alliance, a nonprofit organization that promotes software development according to the manifesto's principles. http://www.agilealliance.org/
79

Scrum
80

which is an agile thing

81

The Agile System Development Life Cycle (SDLC)

Based on Agile software development methods as outlined in the Agile Manifesto A more detailed version of SCRUM Features Pre-Sprint Activity

82

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions

Working software Customer collaboration

over

processes and tools

comprehensive documentation contract negotiation

over

over

Responding to change

over

following a plan

Figure 14

That is, while there is value in the items on the right, we value the items on the left more

83

Principles behind the Agile Manifesto

1.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7.

Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

8.

2.

9.

3.

10.

4.

11.

5.

12.

6.

84

The Agile System Development Life Cycle (SDLC)

Figure 15

85

The Agile Scrum System Development Life Cycle (SDLC)

Pre sprint

Sprint Figure 16

Post sprint

86

SCRUM As Is

Figure 17
87

Scrum/Agile Scrums three aspects

Process People
Products
88

Figure 18

Sprint

Process

89

People

(agile scrum)

team

Scrum master

Product Owner

Figure 19
90

People -- Product Owner Role

Figure 20
91

People -- Product Owner Role ( Business Analysis 101)

Product owners bridge the communication between the team and their stakeholders. As Figure shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole. Product owners are empowered. The product owner is the single person whom is responsible for prioritizing requirements and for providing the details explaining the requirements to the team. At scale this becomes a bit more complex, as you'll see below.

Product owners facilitate communication. Product owners need good communication skills, including agile modeling skills. They also need to know who the stakeholders are, interact with them regularly, and when needed facilitate the interaction which the team has w them. Although it's convenient for deliver teams to think of product owners as the "one neck wring" because it puts the burden of requirements responsibility on them, the reality is that the product owner can't possibly know all the details known by the true range of stakeholders at all points in time and as a result will need to bring stakeholder experts to the team to share their expertise with the team at appropriate times. The implication is that the product owner isn't always the direct source of requirements.
92

People -- Product Owner Role ( Business Analysis 101)

Product owners prefer direct means of communication. There is significant evidence that the worst way to communicate information between people is via documentation, and that the most effective way is face-to-face around a shared sketching Product owners need many business analysis skills. They need to be skilled in techniques to identify stakeholder needs,environment. Agilists in general prefer to avoid interim documentation and instead use more effective means for agile communication negotiate priorities between repeating stakeholder factions, and then collaborate with developers to ensure that the requirements are implemented effectively.

93

The Agile System Development Life Cycle (SDLC)

Figure 21
94

The Agile System Development Life Cycle (SDLC)Online Reference Guide

http://guide.agilealliance.org/

95

Secrets to success --Agile-Scrum Development Early and often Focus on value Release focus Avoid eating elephants Test first approach to requirements Done-Done Communication, communication, communication (as usual)

(James Shore, The Art of Agile Development)

96

References
1.

Agile Software Development with Scrum

Ken Schwaber, Mike Beedle Prentice Hall 2001

2. 3. 4.

http://www.mountaingoatsoftware.com/pres/ RedistributableIntroToScrum.ppt http://www.controlchaoscom/ http://runningagile.com/2008/01/19/quickies -sticky-notes-20/scrum-board/

97

References by Topic
Estimating the Product Backlog: http://www.mountaingoatsoftware.com/scrum/product-backlog Writing User Stories: http://www.agilemodeling.com/artifacts/userStory.htm Agile Manifesto: http://agilemanifesto.org/

Product Owner ( BA Role) http://www.projecttimes.com/elizabeth-larson/is-the-business-analyst-aproduct-owner-or-tester-on-agile-projects.html http://www.agilemodeling.com/essays/productOwner.htm Burn Chart : http://joel.inpointform.net/software-development/burn-down-charts-tutorialsimple-agile-project-tracking/

98

References by Topic
Empirical Process Control: http://barryhawkins.com/blog/2012/04/13/empirical-process-controlwhy-scrum-works/ User Storys: http://www.westborosystems.com/2010/02/user-story-examples/ SCRUM Artifacts: http://www.scrumalliance.org/pages/scrum_artifacts

99

Questions

100

Thank You

101