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.
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
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.
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
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