AGILE METHODOLOGY
•Download as PPTX, PDF•
2 likes•1,128 views
This document provides an overview of the Agile (Scrum) methodology. It describes Scrum as a framework for project management that uses short development cycles called sprints. Key aspects of Scrum covered include roles like the product owner and scrum master, meetings like the daily scrum and sprint review, and terminology such as user stories, product backlog, and burn-down charts. The document outlines benefits of Agile like improved visibility and quality, as well as some potential disadvantages around documentation and management effort.
Report
Share
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to AGILE METHODOLOGY
Similar to AGILE METHODOLOGY (20)
AGILE METHODOLOGY
- 2. AGENDA Overview Of Agile Why Agile Benefits Of Agile Disadvantages Scrum Roles : Product owner, Scrum master, Dev team, Stakeholder Scrum Meetings : Sprint planning, daily scrum, Sprint review, sprint retrospective Scrum Terminology
- 3. OVERVIEW OF AGILE (Scrum) : 1. Agile methodology is an alternative to traditional project management, typically used in software development. 2. Scrum is the most popular way of introducing Agility due to its simplicity and flexibility 3. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. 4. Scrum has only three roles: Product Owner, Team, and Scrum Master. 5. Scrum has five meetings: Backlog Grooming , Sprint Planning, Daily Scrum (15-minute standup), the Sprint Review Meeting, and the Sprint Retrospective Meeting. 6. Other Agile methodology : Kanban, Extreme Programming (XP)
- 4. WHY AGILE : 1. Quality : Testing is integrated throughout the lifecycle. 2. Visibility : This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself. 3. Business Engagement/Customer Satisfaction : Product release in form of Sprint. 4. Flexibility : We can change the requirements easily. 5. Speed-to-market : Early & regular releases.
- 5. BENEFITS OF AGILE Ability to manage changing priorities. Improved project visibility. Faster time to market. Enhanced S/w quality. Reduce risk. Low cost. Customer collaboration.
- 6. SOME DISADVANTAGES • Lack of importance on Documentation. • Time limit. • Need better Team work. • More management effort required for monitoring and controlling activities.
- 7. SCRUM ROLES • The Product Owner ( product owner will be stakeholder also) • The Scrum Master • The Development Team • Stakeholders
- 8. PRODUCT OWNER The Product Owner is responsible for delivering product value. The Product Owner prioritizes the list of items on the Product Backlog. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next. Create and maintain the Release Burndown Chart. Clearly communicate the business case to the Team and Stakeholders. Report progress to the Stakeholders regularly.
- 9. SCRUM MASTER The Scrum Master is responsible for ensuring Scrum is understood and enacted. Facilitate Sprint Planning, Daily Scrums, Sprint Reviews and Retrospective Meetings. Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
- 10. THE DEVELOPMENT TEAM The Team is ultimately responsible for committing to a Sprint goal and promising to deliver it within the time boxed Sprint. The Team is self-managing and self-organized. Team commits to the Sprint, they must ensure that they can deliver on what they promised. Help create and maintain the Sprint Backlog, Sprint Burndown Chart and Task Board. Demonstrate the product at the end of each Sprint — during the Sprint Review.
- 11. STAKEHOLDER The Stakeholder is anyone who has an interest or stake in the project. This can be the direct managers of the Team members, the persons providing funding for the project as well. Stakeholders are responsible for communicating their needs, and providing feedback on the product. Provide direct feedback to the Team during Sprint Reviews.
- 12. SCRUM EVENTS Sprint Planning Daily Scrum Sprint Review Sprint Retrospective
- 13. SPRINT PLANNING The work to be performed in the Sprint is planned at the Sprint Planning. Sprint Planning meetings are time-boxed events that determine which product backlog items will be delivered and how the work will be achieved. Topic Discussed In Sprint Planning Meeting : What can be done in this Sprint. How will the chosen work get done? Sprint goal.
- 14. DAILY SCRUM The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily Scrum is held at the same time and place each day to reduce complexity. The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal Topic Discussed In Daily Scrum : What did I do yesterday. What will I do today. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
- 15. SPRINT REVIEW During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. The Sprint Review is the demonstration event for the team to present the work completed during the sprint. The stakeholders or clients give feedback to ensure that the delivered increment met the business need. Topics Discussed In Sprint Review Meeting : The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”. The Development Team demonstrates the work that it has “Done”. The Product Owner discusses the Product Backlog. The Product Backlog may also be adjusted overall to meet new opportunities.
- 16. SPRINT RETROSPECTIVE The Retrospective, or Retro, is the final team meeting in the Sprint to determine what went well, what went wrong, and how the team can improve in the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. Topics Discussed In Sprint Retrospective Meeting : What went well & what went wrong. Create a plan for implementing improvements for remaining sprints.
- 17. SCRUM TERMINOLOGY Sprint User Story Product Backlog Sprint Backlog Definition Of Done Burn down Chart
- 18. SPRINT In the Scrum method of Agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. Scrum sprints used to be 30 days long, but today many teams prefer shorter sprints, such as one-week or two-week sprints. A new Sprint starts immediately after the conclusion of the previous Sprint. During the Sprint: No changes are made that would affect the Sprint Goal. Sprint can’t be delay. Quality goals do not decrease. Only the Product Owner has the authority to cancel the Sprint.
- 19. USER STORY (Requirement) A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. An Agile user story is meant to be short. The user stories should be written by the business in the language of the customer so that it is clear to both the business and the development team what the customer wants and why he wants it. A user story is a very high-level definition of a requirements. Each story is having story point. There will be 2 things in each User Story : 1. Acceptance Criteria 2. Business Rules.
- 20. PRODUCT BACKLOG The Product Backlog is an ordered list of everything that might be needed in the product. The Product Owner is responsible for the Product Backlog including its content, availability, and ordering (Priority basis). A Product Backlog is never complete, As long as a product exists, its Product Backlog also exists. The Product Backlog lists all features, functions, requirements and enhancements that constitute the changes to be made to the product in future releases, Requirements never stop changing, so a Product Backlog is a living artifact.
- 21. SPRINT BACKLOG A sprint backlog is the specific list of items taken from the product backlog which are to be completed in a sprint. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint.
- 22. DEFINITION OF DONE(DOD) Definition of done is crucial to a highly functioning Scrum team. DoD will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well. If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.”
- 23. BURN-DOWN CHART Burn-downs charts are among the most common sprint tracking mechanisms used by Agile practitioners. The first step is to have a task breakdown in place. This is generally done during the sprint planning meeting. Each task should have associated hours (Complete Sprint), which the team decides on during the planning meeting. Once the task breakdown is in place, the ideal burn- down chart is plotted. The ideal reflects progress assuming that all tasks will be completed within the sprint at a uniform rate. Updating Task : Each member picks up tasks from the task breakdown and works on them. At the end of the day, they update effort remaining for the task, along with its status.
- 24. PLANNING POKER Planning poker is a technique which is used to create a Sprint backlog from the Product Backlog. How It Works : To start a poker planning session, the product owner reads a agile user story or describes a feature to the estimators. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The values represent the number of story points. The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time. If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates and the process will continue until they all agreed for that User story else it will get defer.
- 25. DEEPAK AGRAWAL