Agile-Scrum.doc

8/14/2019 Agile-Scrum.doc

1/8

Agile Software Development Methodologies - SCRUM Model

Agile means Ability to move quickly and easily.

Agile software development refers to a group of software development methodologies based on

iterative development, where requirements and solutions evolve through collaboration betweenself-organizing cross-functional teams.

The main features of Agile Development are:-

1. n!remental" terative" AdaptiveAgile Development follows a descriptive approach and builds the system gradually. Typically, ithas to ! weeks of iterations, which includes requirements development and testing. Thus it hasmultiple checkpoints during a pro"ect.

#. Regularl$ delivers %usiness value#ork is broken into stories also known as use-cases and each of them is defined with some

acceptance criteria.&. Colla%orativeAgile Development allows members to work in different modules and does not requirespecialized knowledge.

'. (o )a!*slidingAgile development automatically includes unit testing and continuous integration testing in a testdriven development method. Also, it leaves little scope of failure as regression testing is also acrucial part of Agile Development.

Different methodologies adopted in Agile Development are $-%. &'treme (rogramming)*(+

. crum. rystal!. Adaptive oftware Development )A D+/. 0eature Driven Development )0DD+1. Dynamic ystems Development 2ethod)D D2+3. *4reed

S!rum Methodolog$:

The name derived from 5ugby, crum is the term for a group of players engaged with each other

to get a "ob done. crum allows us to focus on delivering the highest business value in theshortest time. 6t allows us to rapidly and repeatedly inspect actual working software )every twoweeks to one month called as Sprints +. The business sets the priorities. 7ur teams self-manageto determine the best way to deliver the highest priority features. 6n every print anyone can seereal working software and decide to release it as is or continue to enhance for ne't iteration.(roduct is designed, coded, and tested during the sprint.


2/8

+ow S!rum ,or*s

S!rum ramewor*

Roles: (roduct 7wner, crum 2aster, Team Ceremonies: print (lanning, print 5eview, print 5etrospective, 8 Daily crum

2eeting Artifa!ts: (roduct 4acklog, print 4acklog, and 4urndown hart.

/rodu!t 0wner: (roduct 7wner is responsible for communicating the vision of the product tothe development team. (roduct 7wner decides on release dates and (rioritize features accordingto customer requirements, Ad"ust features and priority for every iteration as needed, Accept orre"ect work results. The (roduct 7wner will be responsible for the profitability of the product)576+.


3/8

S!rum Master: The crum 2aster is responsible for making sure a crum team lives by thevalues and practices of crum. The crum 2aster is often considered a coach for the team,helping the team do the best work it possibly can. The crum 2aster can also be thought of as a

process owner for the team, creating a balance with the pro"ect9s key stakeholder, who is referredto as the product owner.

The crum 2aster does anything possible to help the team perform at their highest level. Thisinvolves removing any impediments to progress, facilitating meetings, and doing things likeworking with the product owner to make sure the product backlog is in good shape and ready forthe ne't sprint. The crum 2aster role is commonly filled by a pro"ect manager or a technicalteam leader but can be anyone.

Si Attri%utes of a 2ood S!rum Master: Responsi%le: A crum 2aster does assume responsibility for the team:s adoption of

crum and practice of it. +um%le $ A good crum 2aster is not in it for ego. Colla%orative: A good crum 2aster will work to ensure a collaborative culture e'ists

within the team Committed: The crum 2aster must feel the same high level of commitment to the

pro"ect and the goals of the current sprint as do team members. nfluential: To be successful crum 2aster will need to influence others both on the

team and outside it. 3nowledgea%le: The best crum 2asters have the technical, market, or specific

knowledge to help the team in pursuit of its goal.

S!rum Team: The crum Team builds the product based on the customer needs. Team consistsof a cross-functional group of people like 4usiness Analysts, (rogrammers, ;6 Designers, andTesters who are responsible for delivering potentially shippable increments of (roduct at the endof every print. Typically involves /


4/8

A sprint goal is a short, one- or two-sentence, description of what the team plans to achieveduring the sprint. The sprint goal can be used for quick reporting to those outside the sprint. Thesuccess of the sprint will later be assessed during the print 5eview 2eeting against the sprintgoal, rather than against each specific item selected from the product backlog .

The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. &ach task on the sprint backlog is also usually estimated.

Sprint: A scrum sprint is a set period of time during which specific work has to be completedand made ready for review. >o outside influence can interfere with the crum team during the

print >o changes are accepted during the sprint. &ach print begins with the Daily crum2eeting.

Dail$ S!rum: During the print the team holds daily meetings called Daily crum. 6deally thedaily scrums are held in the morning as they help set the conte't for the coming day9s work.Daily scrums are strictly timebo'ed to fifteen minutes. 6t is not a problem solving session. 6t isnot a way to collect information about #?7 is behind the schedule. 6t is a meeting in which

team members make commitments to each other and to the crum 2aster. 6t is a good way for acrum 2aster to track the progress of the Team.

During the daily scrum each team member answers the following three questions$%. #hat did you do yesterday@

. #hat will you do today@

. Are there any impediments in your way@
http://www.mountaingoatsoftware.com/scrum/sprint-review-meetinghttp://www.mountaingoatsoftware.com/scrum/product-backloghttp://www.mountaingoatsoftware.com/scrum/product-backloghttp://www.mountaingoatsoftware.com/scrum/sprint-backloghttp://www.mountaingoatsoftware.com/scrum/product-backloghttp://www.mountaingoatsoftware.com/scrum/sprint-backloghttp://www.mountaingoatsoftware.com/scrum/sprint-review-meeting


5/8

4y focusing on what each person accomplished yesterday and will accomplish today the teamgains an e'cellent understanding of what work has been done and what work remains.

Sprint Review Meeting:At the end of each sprint a print 5eview 2eeting is held. During this meeting the crum team shows what they accomplished during the sprint. Typically this takes the form of a demo of thenew features.

The sprint review meeting is intentionally kept very informal, typically with rules forbidding theuse of (ower(oint slides and allowing no more than two hours of preparation time for themeeting. A sprint review meeting should not become a distraction or significant detour for theteam rather, it should be a natural result of the sprint.(articipants in the sprint review typically include the (roduct 7wner , the crum team, the crum2aster, management, customers, and developers from other pro"ects.

During the sprint review the pro"ect is assessed against the sprint goal determined during theprint planning meeting . 6deally the team has completed each product backlog item brought into

the sprint, but it is more important that they achieve the overall goal of the sprint.

Sprint Retrospe!tive Meeting:

>o matter how good a crum Team is, there is always opportunity to improve. Although a goodcrum team will be constantly looking for improvement opportunities, the team should set aside

a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doingand to find ways to improve. This occurs during the sprint retrospective.

The sprint retrospective is usually the last thing done in a sprint. The entire team, including boththe crum 2aster and the (roduct 7wner should participate. 6t as a start-stop-continue meeting.The crum 2aster can facilitate this meeting by asking everyone to "ust shout out ideas. The

crum 2aster can go around the room asking each person to identify any one thing to start, stopor continue.

After an initial list of ideas has been brainstormed, teams will commonly vote on specific itemsto focus on during the coming sprint. At the end of the sprint, the ne't retrospective if often

begun by reviewing the list of things selected for attention in the prior retrospective.

/rodu!t )a!*log:

The product backlog is a prioritized features list , containing short descriptions of allfunctionality desired in the product. Typically, a crum team and its product owner begin bywriting down everything they can think of easily. This is almost always more than enough for afirst sprint. The product backlog is then allowed to grow and change as more is learned about the

product and its customers.

A typical product backlog comprises the following different types of items$
http://www.mountaingoatsoftware.com/scrum/teamhttp://www.mountaingoatsoftware.com/scrum/product-ownerhttp://www.mountaingoatsoftware.com/scrum/product-ownerhttp://www.mountaingoatsoftware.com/scrum/sprint-planning-meetinghttp://www.mountaingoatsoftware.com/scrum/teamhttp://www.mountaingoatsoftware.com/scrum/product-ownerhttp://www.mountaingoatsoftware.com/scrum/sprint-planning-meeting


6/8

%. 0eatures. 4ugs

. Technical work

!. Bnowledge acquisition

The (roduct 7wner shows up at the sprint planning meeting with the prioritized (roduct 4acklogand describes the top items to the team. The team then determines which items they cancomplete during the coming print. The team then moves items from the (roduct 4acklog to the

print 4acklog. 6n doing this, they e'pand each (roduct 4acklog item into one or more print4acklog tasks so they can more effectively share work during the print. onceptually, the teamstarts at the top of the prioritized (roduct 4acklog and draws a line after the lowest of the high

priority items they feel they can complete. 6n practice it is not unusual to see a team select, fore'ample, the top five items and then two items from lower on the list but that are associated withthe initial five.

Sprint )a!*log:The sprint backlog is the list of tasks identified by the crum team during sprint planning.During sprint planning, the team selects some number of (roduct 4acklog items, usually in theform of user stories, and identifies the tasks necessary to complete each user story. 2ost teamsalso estimate how many hours each task will be needed someone on the team to complete.

During the sprint, team members are e'pected to update the print 4acklog as new informationis available, but minimally once per day. 2any teams will do this during the Daily crum. 7nceeach day, the estimated work remaining in the sprint is calculated and graphed by the crum

2aster, resulting in a print 4urndown chart. 6f the task requires more than %1 hours, it should be broken down further.

Sprint )urn down Chart:


7/8

The print 4urndown hart is a graphical representation of the work remaining over the durationof the print. ;pdated every day, it gives a simple view of the sprint progress. 6t also providesquick visualizations for reference. 6deally should burn down to zero to the end of the print.

Release )urn down Chart:The team tracks its progress against a release plan by updating a 5elease 4urndown chart at theend of each sprint. The horizontal a'is of the 5elease burndown chart shows the sprints thevertical a'is shows the amount of work remaining at the start of each sprint. #ork remaining can

be shown in whatever unit the team prefers--story points, ideal days, team days, and so on.

Agile Testing methodolog$:


8/8

Conte t Driven Testing:onte't Driven testing is the one where the test scenarios are not known before hand. 6t mostly

comes from the conte't in which the application is being e'ecuted. onte't-driven testers choosetheir testing ob"ectives, techniques, and deliverables )including test documentation+ by lookingfirst to the details of the specific situation, including the desires of the stakeholders whocommissioned the testing. The essence of conte't-driven testing is pro"ect-appropriateapplication of skill and "udgment.

onte't-driven testing is about doing the best we can with what we get. 5ather than trying toapply Cbest practices , we accept that very different practices )even different definitions ofcommon testing terms+ will work best under different circumstances.

Rapid Testing:

5apid Testing is a process of defining our own strategies to test the oftware, not necessarilyfollowing any specific (rocess or a 2odel. 6t focuses mainly on identifying the defects asquickly as possible rather than focusing on the end user requirements.

?euristic approach is used in such cases. The tester uses his common sense and previous worke'perience to test the application at various levels in order to figure out where the applicationstands.

Con!lusion:

Agile software development stresses rapid iterations, small and frequent releases, and evolvingrequirements facilitated by direct user involvement in the development process. The roots of;52 are as follows$

Commitment: 4e willing to commit to a goal. crum provides people all the authoritythey need to meet their commitments.

o!us: Do your "ob. 0ocus all your efforts and skills on doing the work that youEvecommitted to doing. DonEt worry about anything else.

0penness: crum keeps everything about the pro"ect visible to everyone. Respe!t: 6ndividuals are shaped by their background and their e'periences. 6t is

important to respect the different people who comprise a team. Courage: ?ave courage to commit, to act, to be open and to e'pect respect.

Agile-Scrum.doc

Documents

Transcript of Agile-Scrum.doc