The document provides a comprehensive overview of Agile Project Management, including the Agile manifesto, principles, and an introduction to the Scrum framework. It details Scrum roles, events, and artifacts while emphasizing continuous delivery, collaboration, and adaptability. Key components such as sprint planning, daily standups, and retrospectives are outlined, demonstrating how Agile methodologies enhance productivity and team efficiency in software development.

1. Agile Project Management
- Manohar Prasad, CSPO® CSM® PSM®

2. Agenda
 Agile Manifesto
 Agile Principles
 Introduction to Scrum
 Scrum Values
 Scrum Roles
 Scrum Events
 Scrum Artifacts
 Sprint Burndown
 Scalability
 User Stories

3. Manifesto for Agile Software Development
 Individuals and interactions over processes
and tools
 Working software over comprehensive
documentation
 Customer collaboration over contract
negotiation
 Responding to change over following a plan

4. Principles of Agile Manifesto
 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.

5. Principles of Agile Manifesto
 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.
 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.

6. Principles of Agile Manifesto
 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.

7. Introduction to Scrum
 Scrum Overview
 Scrum Values
 Scrum Roles
 Scrum Events
 Scrum Artifacts

8. What is Scrum?Scrum
 Scrum:
 Is an agile, lightweight process
 Can manage and control software and product
development
 Uses iterative, incremental practices
 Has a simple implementation
 Increases productivity
 Reduces time to benefits
 Embraces adaptive, empirical systems development
 Is not restricted to software development projects.

9. Scrum Overview

10. Scrum Values

11. Scrum Roles
 Product owner
 Scrum master
 Responsible for the scrum process
 Teaching
 Implementing
 Ensuring
 Scrum team

12. Scrum Artifacts

13. Product Backlog
 Ever changing
 Prioritized list
 Owned by product owner
 Spread sheet example

14. Sprint Backlog
 Consists of selected PBIs negotiated between the
team and the Product Owner during the Sprint
Planning Meeting.
 No changes are made during the Sprint that would
endanger the Sprint Goal.
 Initial tasks are identified by the team during Sprint
Planning Meeting.
 Team will discover additional tasks needed to meet
the Sprint Goal during Sprint execution
 Visible to the team.
 Referenced during the Daily Scrum Meeting

15. Product Backlog & Sprint Backlog

16. Product 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".
 The product capabilities completed during the
Sprints.
 Brought to a usable, releasable state by the end of
each Sprint.
 Released as often as the Product Owner wishes.
 Inspected during every Sprint Review Meeting.

17. Scrum Team

18. Scrum Events
 Sprint planning meeting
 Daily standup meeting
 Sprint review meeting
 Sprint retrospective meeting

19. Scrum Meetings

20. Sprint Planning Meeting
 Stake-holders to refine and re-prioritize the Product
Backlog and Release Backlog and to choose the
goals for the next iteration, usually droved by the
highest business value and risk
 Scrum team and Product Owner meet to consider
how to achieve the requests, and to create a sprint
backlog of tasks to meet the goals

21. Daily Standup Meeting
 Three things to talk in 15 minutes
 What did I accomplish yesterday?
 What will I do today?
 What obstacles are impeding my progress?
 Why standup meeting?
 Promote individual’s commitment to the team
 Promote close working relationship
 Identify issues in timely fashion

22. Sprint Review Meeting
 During the sprint review, the project is assessed
against the sprint goal determined during the sprint
planning meeting. Ideally, the team has completed
each product backlog item brought into the sprint,
but it's more important that they achieve the overall
goal of the sprint.
 Sprint review typically include the product owner,
the ScrumMaster, development team, and the
product sponsors or stakeholders.

23. Sprint Retrospective Meeting
 The sprint retrospective is usually the last thing
done in a sprint.
 The entire team, including both the ScrumMaster
and the product owner should participate.
 The sprint retrospective is of 3 hours duration for a
four week sprint.
 The sprint retrospective is a meeting facilitated by
the ScrumMaster at which the team discusses the
just-concluded sprint and determines what could be
changed that might make the next sprint more
productive.

24. Roles of Scrum Master
 Works with the organization to make Scrum possible
 Ensures Scrum is understood and enacted
 Creates an environment conducive to team self-
organization
 Shields the team from external interference and
distractions to keep it in group flow
 Promotes improved engineering practices
 Helps resolve impediments
 Has a leadership role
 Has no management authority over the team

25. Scrum Master

26. Roles of 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
 Decides whether to release
 Decides whether to continue development
 Considers stakeholder interests
 May contribute as a team member
 Has a leadership role

27. Roles of Development Team
 Cross-functional (e.g., includes members with testing skills, and
others not traditionally called developers: business analysts, designers,
domain experts, etc.)
 Self-organizing / self-managing, without externally assigned roles
 Plans one Sprint at a time with the Product Owner
 Has autonomy regarding how to develop the increment
 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.
 6 ± 3 members
 Has a leadership role

28. Sprint Burndown Chart
 Summation of total team work remaining within one Sprint.
 It is updated daily.
 May go up before going down.
 Intended to facilitate team self-organization.
 Fancy variations, such as itemizing by point person or adding
trend lines, tend to reduce effectiveness at encouraging
collaboration.
 Seemed like a good idea in the early days of Scrum, but in
practice has often been misused as a management report,
inviting intervention. The Scrum Master should discontinue use
of this chart if it becomes an impediment to team self-
organization.

29. Sprint Burndown Chart

30. Scalability
 Typical individual team is 7 ± 2 people
 Scalability comes from teams of teams
 Factors in scaling
 Type of application
 Team size
 Team dispersion
 Project duration
 Scrum has been used on multiple 500+ person
projects

31. User Stories
 Instead of Use Cases, Agile project owners do "user stories"
 Who (user role) – Is this a customer, employee, admin,
etc.?
 What (goal) – What functionality must be
achieved/developed?
 Why (reason) – Why does user want to accomplish this
goal?
As a [user role], I want to [goal], so I can [reason].
 Example:
 "As a user, I want to log in, so I can access subscriber
content.”

32. Questions!