The document provides an overview of Agile methodology and Scrum framework. It describes that Agile is an alternative project management approach that uses short iterative cycles called sprints to incrementally deliver working software. Scrum is the most commonly used Agile framework and involves roles of Product Owner, Scrum Master, and team. It uses artifacts like Product Backlog and Sprint Backlog and events like Sprint Planning, Daily Scrum, and Sprint Review.

1. Agile
(SCRUM)
Methodology
Dominic Cushnan
@domcushnan

2. What is Agile Methodology?
➔ Agile methodology is an alternative to traditional project
management, typically used in software development. It helps
teams respond to unpredictability through incremental,
iterative work cadences, known as sprints.
➔ Agile methodologies are an alternative to waterfall, or
traditional sequential development.

3. ➔ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
➔ Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
➔ Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
➔ Business people and developers must work together daily throughout the project.
➔ Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
➔ The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
Principles behind the Agile Manifesto

4. Principles behind the Agile Manifesto
➔ Working software is the primary measure of progress.
➔ Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
➔ Continuous attention to technical excellence and good design enhances agility.
➔ Simplicity--the art of maximizing the amount of work not done--is essential.
➔ The best architectures, requirements, and designs emerge from self-organizing teams.
➔ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.

5. What is Scrum?
➔ It is one of many iterative and incremental software development agile process for
managing product development.
➔ It is a framework within which people can address complex adaptive problems,
while productively and creatively delivering products of the highest possible value.
➔ It is based on multiple small teams working in an intensive and interdependent
manner. The teams in the organization work together while constantly focusing on
their common interests.
➔ Scrum has three roles: Product Owner, Scrum Master, and Team.

6. Scrum involves:
➔ Initial appointment of a project manager called the "scrum master."
➔ Definition and prioritization of tasks to be done.
➔ Planning sessions for each task.
➔ Daily meetings among teams.
➔ Identification and evaluation of potential project risks and process pitfalls.
➔ Execution of projects in brief, high-intensity, frequent work sessions.
➔ Reviews of progress and evaluations of completed projects.
➔ Openness to constructive criticism and ideas for improvement.

7. The Scrum Process
Scrum blends all
development activities
into each iteration,
adapting to discovered
realities at fixed
intervals.

8. The Calendar Template

9. Scrum
Roles
Scrum Roles consists of a Product Owner,
the Scrum Master, and the Development
Team.

10. Scrum Roles - Product Owner
➔ Single person responsible for maximizing the return on investment (ROI) of the development
effort
➔ Responsible for product vision
➔ Constantly re-prioritizes the Product Backlog, adjusting any long term expectations such as
release plans
➔ Final arbiter of requirements questions
➔ Accepts or rejects each product increment
➔ Decides whether to ship
➔ Decides whether to continue development
➔ Considers stakeholder interests
➔ May contribute as a team member

11. Scrum Roles - Scrum Master
➔ Facilitates the Scrum process
➔ Helps resolve impediments
➔ Creates an environment conducive to team self-organization
➔ Captures empirical data to adjust forecasts
➔ Shields the team from external interference and distractions to keep it in group flow (a.k.a. the
zone)
➔ Enforces timeboxes
➔ Keeps Scrum artifacts visible
➔ Promotes improved engineering practices

12. Scrum Roles - Development Team
➔ Cross-functional (e.g., includes members with testing skills, and often others not traditionally
called developers: business analysts, domain experts, etc.) Self-organizing / self-managing,
without externally assigned roles
➔ Negotiates commitments with the Product Owner, one Sprint at a time
➔ Has autonomy regarding how to reach commitments
➔ Intensely collaborative
➔ Most successful when located in one team room, particularly for the first few Sprints
➔ Most successful with long-term, full-time membership. Scrum moves work to a flexible
learning team and avoids moving people or splitting them between teams.
➔ 3-9 members (originally 7 ± 2 members)

13. Scrum
Artifacts
These represent work or value to provide
transparency and opportunities for
inspection and adaptation.

14. Scrum Artifacts - Product Backlog
The Product Backlog is an ordered list of everything that might be
needed in the product and is the single source of requirements for
any changes to be made to the product. The Product Owner is
responsible for the it, including its content, availability, and ordering.
It lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future
releases.

15. Scrum Artifacts - Product Backlog
➔ Force-ranked list of desired functionality
➔ Visible to all stakeholders
➔ Any stakeholder (including the Team) can add items
➔ Constantly re-prioritized by the Product Owner
➔ Items at top are more granular than items at bottom
➔ Maintained during the Backlog Refinement Meeting

16. Scrum Artifacts - Product Backlog
Product Backlog Item (PBI)
➔ Specifies the what more than the how of a customer-centric feature
➔ Often written in User Story form
➔ Has a product-wide definition of done to prevent technical debt
➔ May have item-specific acceptance criteria
➔ Effort is estimated by the team, ideally in relative units (e.g., story points)
➔ Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams

17. Scrum Artifacts - Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the
Sprint, plus a plan for delivering the product Increment and realizing
the Sprint Goal.
The Sprint Backlog is a forecast by the Development Team about what
functionality will be in the next Increment and the work needed to
deliver that functionality into a “Done” Increment.

18. Scrum Artifacts - Sprint Backlog
➔ Consists of committed PBIs negotiated between the team and the Product
Owner during the Sprint Planning Meeting
➔ Scope commitment is fixed during Sprint Execution
➔ Initial tasks are identified by the team during Sprint Planning Meeting
➔ Team will discover additional tasks needed to meet the fixed scope
commitment during Sprint execution
➔ Visible to the team
➔ Referenced during the Daily Scrum Meeting

19. Scrum Artifacts - Sprint Backlog
Increment
The Increment is the sum of all the Product Backlog items completed
during a Sprint and the value of the increments of all previous
Sprints.
At the end of a Sprint, the new Increment must be “Done,” which
means it must be in useable condition and meet the Scrum Team’s
definition of “Done.”

20. Scrum Artifacts - Sprint Backlog
Sprint Backlog is often
represented with an
“information radiator” such
as a physical task board
(Scrum Board).

21. An example of a physical Scrum Board

22. Scrum
Events
Prescribed events are used in Scrum to
create regularity and to minimize the need
for meetings not defined in Scrum. All
events are time-boxed events, such that
every event has a maximum duration.

23. Scrum Events - Sprint Planning
The work to be performed in the Sprint is planned at the Sprint
Planning. This plan is created by the collaborative work of the entire
Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a
one-month Sprint. For shorter Sprints, the event is usually shorter.
The Scrum Master ensures that the event takes place and that
attendants understand its purpose. The Scrum Master teaches the
Scrum Team to keep it within the time-box.

24. Scrum Events - Sprint Planning
Sprint Planning answers the following:
➔ What can be delivered in the Increment resulting from the
upcoming Sprint?
➔ How will the work needed to deliver the Increment be achieved?

25. Sprint Goal
The Sprint Goal is an objective set for the Sprint. It provides guidance
to the Development Team on why it is building the Increment. It is
created during the Sprint Planning meeting.
Scrum Events - Sprint Planning

26. Scrum Events - Daily Scrum/Daily Stand-up
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.
This is done by inspecting the work since the last Daily Scrum and
forecasting the work that could be done before the next one. The
Daily Scrum is held at the same time and place each day to reduce
complexity.

27. Scrum Events - Daily Scrum/Daily Stand-up
During the meeting, the Development Team members explain:
➔ What did I do yesterday that helped the Development Team meet
the Sprint Goal?
➔ What will I do today to help the Development Team meet the
Sprint Goal?
➔ Do I see any impediment that prevents me or the Development
Team from meeting the Sprint Goal?

28. Scrum Events - Daily Scrum/Daily Stand-up
The Development Team or team members often meet immediately
after the Daily Scrum for detailed discussions, or to adapt, or replan,
the rest of the Sprint’s work.
Daily Scrums improve communications, eliminate other meetings,
identify impediments to development for removal, highlight and
promote quick decision-making, and improve the Development
Team’s level of knowledge. This is a key inspect and adapt meeting.

29. Scrum Events - Sprint Review/Demo
A Sprint Review is held at the end of the Sprint to inspect the
Increment and adapt the Product Backlog if needed. During the
Sprint Review, the Scrum Team and stakeholders collaborate about
what was done in the Sprint.
This is an informal meeting, not a status meeting, and the
presentation of the Increment is intended to elicit feedback and foster
collaboration.

30. Scrum Events - Sprint Review/Demo
The Sprint Review includes the following elements:
➔ Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
➔ The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
➔ The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were
solved;
➔ The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
➔ The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to
date (if needed);
➔ The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint
Planning;
➔ Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next;
and,
➔ Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.

31. Scrum Events - Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to
inspect itself and create a plan for improvements to be enacted
during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to
the next Sprint Planning.

32. Scrum Events - Sprint Retrospective
The purpose of the Sprint Retrospective is to:
➔ Inspect how the last Sprint went with regards to people,
relationships, process, and tools;
➔ Identify and order the major items that went well and potential
improvements; and,
➔ Create a plan for implementing improvements to the way the
Scrum Team does its work.

33. CREDITS
Presentation template by SlidesCarnival
Photographs by Death to the Stock Photo (license)
SOURCES
http://agilemethodology.org/
http://scrummethodology.com/
http://searchsoftwarequality.techtarget.com/definition/Scrum
http://scrumreferencecard.com/scrum-reference-card/
http://www.scrumguides.org/scrum-guide.html
http://www.synagila.com/wp-content/uploads/2014/01/scrum-board.jpg
https://amareshv.files.wordpress.com/2011/03/fairydustboard_20110324.jpg
https://www.mountaingoatsoftware.com/agile/new-to-agile-or-scrum