You are on page 1of 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 between self-organizing cross-functional teams. The main features of Agile Development are:1. n!remental" terative" Adaptive Agile Development follows a descriptive approach and builds the system gradually. Typically, it has to ! weeks of iterations, which includes requirements development and testing. Thus it has multiple 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%orative Agile Development allows members to work in different modules and does not require specialized knowledge. '. (o )a!*sliding Agile development automatically includes unit testing and continuous integration testing in a test driven development method. Also, it leaves little scope of failure as regression testing is also a crucial 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 the shortest time. 6t allows us to rapidly and repeatedly inspect actual working software )every two weeks to one month called as Sprints+. The business sets the priorities. 7ur teams self-manage to determine the best way to deliver the highest priority features. 6n every ,print anyone can see real 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.

+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 to the development team. (roduct 7wner decides on release dates and (rioritize features according to customer requirements, Ad"ust features and priority for every iteration as needed, Accept or re"ect work results. The (roduct 7wner will be responsible for the profitability of the product )576+.

S!rum Master: The ,crum 2aster is responsible for making sure a ,crum team lives by the values 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 referred to as the product owner. The ,crum 2aster does anything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the ne't sprint. The ,crum 2aster role is commonly filled by a pro"ect manager or a technical team leader but can be anyone. Si1 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 consists of a cross-functional group of people like 4usiness Analysts, (rogrammers, ;6 Designers, and Testers who are responsible for delivering potentially shippable increments of (roduct at the end of every ,print. Typically involves /<%= people, teams are self-organizing and has the autonomy to determine how and when to complete its work.

Sprint /lanning Meeting:


The ,print (lanning 2eeting is attended by the product owner, ,crum 2aster, and the entire ,crum Team. During the sprint planning meeting the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. There are two defined artifacts that result from a sprint planning meeting$ %. A sprint goal . A sprint backlog

A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. The sprint goal can be used for quick reporting to those outside the sprint. The success of the sprint will later be assessed during the ,print 5eview 2eeting against the sprint goal, 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 completed and 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 ,crum 2eeting. Dail$ S!rum: During the ,print the team holds daily meetings called Daily ,crum. 6deally the daily 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 is not 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 a ,crum 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@

4y focusing on what each person accomplished yesterday and will accomplish today the team gains 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 the new features. The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of (ower(oint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the teamA rather, it should be a natural result of the sprint. (articipants in the sprint review typically include the (roduct 7wner, the ,crum team, the ,crum 2aster, management, customers, and developers from other pro"ects. During the sprint review the pro"ect is assessed against the sprint goal determined during the ,print 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 good ,crum 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 doing and 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 both the ,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, stop or continue. After an initial list of ideas has been brainstormed, teams will commonly vote on specific items to 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 all functionality desired in the product. Typically, a ,crum team and its product owner begin by writing down everything they can think of easily. This is almost always more than enough for a first 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$

%. 0eatures . 4ugs -. Technical work !. Bnowledge acquisition The (roduct 7wner shows up at the sprint planning meeting with the prioritized (roduct 4acklog and describes the top items to the team. The team then determines which items they can complete 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 ,print 4acklog tasks so they can more effectively share work during the ,print. .onceptually, the team starts 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, for e'ample, the top five items and then two items from lower on the list but that are associated with the 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 the form of user stories, and identifies the tasks necessary to complete each user story. 2ost teams also 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 information is available, but minimally once per day. 2any teams will do this during the Daily ,crum. 7nce each 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:

The ,print 4urndown .hart is a graphical representation of the work remaining over the duration of the ,print. ;pdated every day, it gives a simple view of the sprint progress. 6t also provides quick 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 the end of each sprint. The horizontal a'is of the 5elease burndown chart shows the sprintsA the vertical 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$:

Conte1t 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 choose their testing ob"ectives, techniques, and deliverables )including test documentation+ by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of conte't-driven testing is pro"ect-appropriate application of skill and "udgment. .onte't-driven testing is about doing the best we can with what we get. 5ather than trying to apply Cbest practices,D we accept that very different practices )even different definitions of common 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 necessarily following any specific (rocess or a 2odel. 6t focuses mainly on identifying the defects as quickly 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 work e'perience to test the application at various levels in order to figure out where the application stands. Con!lusion: Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements 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 authority they need to meet their commitments. .o!us: Do your "ob. 0ocus all your efforts and skills on doing the work that youEve committed 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.

You might also like