This document provides an overview of agile software development methodologies, focusing on Scrum. It describes the traditional waterfall methodology and its limitations. Agile methodologies like Scrum promote iterative development through collaboration between cross-functional teams. Scrum uses sprints, daily stand-ups, sprint reviews and retrospectives. Key roles include the product owner, Scrum master, and self-organizing development team. The product backlog and sprint backlog are key artifacts that help manage work in progress.

1. AGILE
METHODOLOGY
SCRUM

2. Software Development Methodology
A software development methodology or system development methodology in
software engineering is a framework that is used to structure, plan, and control the
process of developing an product.

3. Traditional Waterfall Methodology
● Waterfall methodology is another name for the more traditional approach to software development
● You complete one phase(e.g. development) before moving on to the other phase(e.g. testing).
● You rarely aim to re-visit a phase once it is completed.
● This approach is highly risky, often more costly and generally less efficient than Agile approaches.

4. Agile Methodology and Scrum
● 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.
● It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach,
and encourages rapid and flexible response to change.
● Scrum is an agile way to manage a project, usually software development.
● Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum
as methodology, think of it as a framework for managing a process.

5. Scrum

6. Sprint - Characteristics
● Self-organizing teams
● Product progresses in a series of “sprints”
● The sprints can be of any duration(every two weeks to one month), we use two week sprint
● Every two weeks to a month anyone can see real working software and decide to release it as is or continue
to enhance for another iteration.
● Requirements are captured as items in a list of “product backlog”
● The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest
priority features.
● Product is designed, coded, and tested during the sprint

7. Sequential vs Overlapping Development

8. Scrum Framework

9. Scrum Framework - Roles

10. Product Owner
● Define the features of the product
● Decide on release date and content
● Be responsible for the profitability of the product
● Prioritize features according to market value
● Adjust features and priority every iteration, as needed
● Accept or reject work results.

11. The Scrum Master
● Represents management to the project
● Responsible for enacting Scrum values and practices
● Removes impediments
● Ensure that the team is fully functional and productive
● Enable close cooperation across all roles and functions
● Shield the team from external interferences

12. The Scrum Team
● Typically 5-10 people
● Cross-functional
○ QA
○ Programmers
○ UI Designers, etc.
● Membership can change only between sprints
● Each team member speaks about his last day’s progress and his task to be worked on the current day.

13. Scrum Framework - Ceremonies

14. Sprint Plan Meeting

15. Sprint Planning
● Before the start of a sprint
● Team selects items from the product backlog they can commit to completing
● Sprint backlog is created
○ Tasks are identified and each is estimated (1-16 hours)
○ Collaboratively, not done alone by the ScrumMaster
● High-level design is considered

16. Scrum Meeting
● On each day of a sprint, the team holds a daily scrum meeting called the "daily scrum.”
● Meetings are typically held in the same location and at the same time each day.
● Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day's work.
● These scrum meetings are strictly time-boxed to 15 minutes.
● This keeps the discussion brisk but relevant.

17. Sprint Review or Triage
● Towards the end of the sprint
● Team presents what it accomplished during the sprint
● Typically takes the form of a demo of new features or underlying architecture
● Informal
○ 2-hour prep time rule
○ No slides
● Whole team participates

18. Sprint Retrospective Meeting
● Periodically take a look at what is and is not working
● Typically 15–30 minutes
● Done after every sprint

19. Scrum Framework - Artifacts

20. Product backlog
● Requirements for a system, expressed as a prioritized list of Backlog Items or all desired work on the project
● Ideally expressed such that each item has value to the users or customers of the product
● Is managed and owned by a Product Owner
● Spreadsheet (typically)
● Prioritized by the product owner
● Reprioritized at the start of each sprint

21. Sprint Goal - Sprint Backlog
● A subset of Product Backlog Items, which define the work for a Sprint
● Is created ONLY by Team members
● Each Item has it’s own status
● Should be updated every day
● If a task requires more than 8 hours, it should be broken down
● Team can add or subtract items from the list. Product Owner is not allowed to do it

22. Where to go next?
● www.mountaingoatsoftware.com/scrum
● www.scrumalliance.org
● www.controlchaos.com
● scrumdevelopment@yahoogroups.com

23. Thank You