1. Agile Project Management Methodology Scrum Overview
Susan Lynn, PMP, CSM

2. Methodology Overview Objectives Agile Overview & Principles Scrum
Roles and Team Concepts
Scrum Framework
Artifacts
Release Planning
Sprint Planning
Sprints
Daily Scrum Meetings (Stand-ups)
Demos
Retrospectives

3. Agile Overview
Agile is a software development philosophy centered on a core set of values and principles.
The basic values and principles of Agile development were initially outlined in the Agile Manifesto.
The Agile Manifesto places value on:
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. Agile Principles
Agile principles are based on the values presented in the Agile Manifesto:
Customer satisfaction by rapid, continuous delivery of useful software
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Even late changes in requirements are welcomed
Close, daily cooperation between business people & developers
Face-to-face conversation is the best form of communication (Co- location when possible)
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances

5. Scrum

6. Scrum Scrum “by the book” includes Roles/Team concepts
Scrum Master
Product owner
Team
Release planning
Sprint planning meetings
Daily stand-ups
Demos
Retrospectives

7. Roles & Team Concepts There are only 3 roles in Scrum:
Product Owner
Team
Scrum Master
All management responsibilities in a project are divided among these three roles.

8. Roles: Product Owner
Responsible for representing the interests of everyone with a stake in the project and its resulting system
Defines a Product Development roadmap
Prioritizes stories in the Product Backlog
Prepared to present vision to the development team
Maintains enough detail of each story in anticipation of the next level of planning
Open to negotiations that will occur

9. Roles: Team Includes developers, business analysts, QA, UI developers
Responsible for developing functionality; responsible for figuring out how to turn Product Backlog into an increment of functionality within a sprint and managing their own work to do so
Team members are collectively responsible for the success of each iteration and of the project as a whole.
Hands on the keyboard
Own the estimates and make tasks commitments
Report daily status
Self-organizing and self-disciplined
Decisions made collaboratively
Cooperative development – role sharing

10. Roles: Scrum Master
Acts as a sheepdog for the team – protects the team, eliminates distractions, removes roadblocks, safeguards the process
Fosters team communications and team decisions (doesn’t make the decisions, only guides the team decision process)
Ensures that everyone follows Scrum rules and practices
Maintains unrelenting dedication to the team’s success in meeting its commitments

11. Scrum Framework
Scrum is an iterative, incremental software development framework where software is delivered in small cycles called Sprints
Core Elements
Product Backlog
Release Planning
Sprint Planning Meeting
Sprint Backlog
Daily Scrum (Standup) Meetings
Sprint Review Meeting & Demo
Sprint Retrospective
Define these terms here

12. Artifacts Product Backlog List of prioritized features or work items
Dynamic – it continually evolves as the product and the environment in which it will be used evolves.
Higher priority items should have more thought and details while the lower priority items have fewer details.
The Product Backlog is owned by the Product Owner who is responsible for the contents, prioritization, and availability of the Product Backlog.
A Product Backlog is never complete. As long as a product exists, the Product Backlog exists. New items can be added at any time to the Product Backlog.
Sprint Backlog
Defines the work or tasks as defined by the Team in order to turn a requirement into working software.
It is a highly visible, real-time picture of the work that the Team plans to accomplish during the Sprint.
The Team owns the Sprint Backlog
Created during the Sprint planning meeting when the Team pulls items from the Product Backlog, breaks them into tasks, estimates the tasks and then commits to delivering the feature.
User Stories
Lightweight descriptions of the functionality that will be valuable to a user of a system
Acceptance Tests/Criteria
Specify all the rules that developers need to follow when implementing a story
Associated with a User Story
Epics
Groupings of User Stories that relate to a single feature
the Agile Manifesto states that we value working software over comprehensive documentation. This does not mean “no” documentation.
Defects are part of the backlog

13. User Stories
A user story is a system requirement written in the language of the business user, and serves as a reminder to have a conversation about a requested feature
Stories are written using this form:
As a <type of user>, I need/want to <function> , so that I can <achieve a goal>
Example: As a site user, I can enter a company keyword and receive a list of matching companies, so that I can target my search to a specific set of companies

14. Acceptance Criteria
Acceptance Criteria describe how to verify the goal of the user story has been achieved
They are how we know a user story is ‘done’
Examples:
“Submit button is present at bottom of page.”
“Icon in header links to home page.”

15. Release Planning
The process of defining a high-level scope and plan that covers a time period longer than a Sprint
A typical release will last one to three months and include as many as twelve Sprints, depending upon the length of Sprints
The release plan sets expectations abut the scope and timeframe of development and serves as a guidepost for the team to perform individual Sprint planning and track progress against ‘the whole’
A release is defined by:
Theme
Delivery Date
Feature Set (backlog)
Release planning is NOT a commitment to precise details
Since it is impossible to know everything up front, the focus is on creating a rough plan to give the project broad direction and to discuss the various tradeoffs that need to be made – like scope versus schedule
Release Planning does not always mean that the team will release into the production environment. The release may be made into an internal environment
The plan should be revisited and updated with some frequency

16. Estimating for Release Planning (with Story Points)
Story Points are…
Relative to other work items - example of 10 points is twice as big, complex and/or risky as 5 points.
Specific to a team
Used to define team velocity
At the story or defect level, not at the task level
Determined by the team
Story points are not…
Commitments
Actual hours, not translated to % of sprint
Ways to compare teams
Poker planning cards – 1, 2, 3, 5, 8, 13 or 20 only as values (5 is middle)

17. Sprint Planning

18. Spring Planning
A Sprint planning meeting initiates every Sprint during which the team commits to delivering a certain amount of work
The meeting is time-boxed
The team determines its capacity for the Sprint taking into account knowledge about capacity from previous Sprints, upcoming vacations, holidays, etc.
The Product Owner presents the highest priority items from the backlog to the team
The team discusses the items with the Product Owner, breaks the items into tasks, estimates those tasks, and then volunteers to work each task
The team decides how much of the backlog it can successfully pull into the Sprint, and then commits to delivering that work
Once the team commits, those items become part of the Sprint backlog and cannot be changed

19. Tasks Estimated in hours Defined by Team
Describe the work needed to complete a work item
Volunteered for by Team members
Status is updated daily
To-do hours drive Sprint metrics (burn down)

20. Sprints
A team develops a rhythm of work in delivering working software during each Sprint cycle
Typical Sprint Activities
Daily Stand-ups
Daily tracking of task and story status
Incremental delivery of stories (software) to QA
Coding
Testing – unit, user acceptance, performance, QA
Deliver potentially shippable functionality
Demo
Retrospective
Non-standard Sprints
Sprint 0 or Architecture Sprint
Stabilization Sprint
Sprint 0 or Architecture Sprint
Often the first Sprint in a new release, used to work out technical and logistical issues such as organizing the team and setting up development and test environments
Architectural design is defined
Little, if any functionality is delivered
Stabilization Sprint
The team focuses on system-wide integration and testing, regression testing, fixing defects found during the Stabilization Sprint, preparing for deployment, and documentation.
New functionality is not added during the Stabilization sprint.

21. Daily Stand-ups (Daily Scrum)
On each day of a Sprint, the team holds a meeting to inform each other of progress, planned work, and blocks
During the daily Scrum each team member provides answers to the following three questions:
What did you do yesterday?
What will you do today?
Are there any impediments in your way?
It is NOT used as a problem-solving or issue resolution meeting; issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily Scrum
It is a meeting in which team members make commitments to each other about what they will accomplish that day
Meetings are typically held in the same location and at the same time each day
The meeting should last no longer than 15 minutes and everyone should be standing

22. Scrum of Scrums A way of scaling Scrum
Meetings that allow multiple teams to discuss their work, focusing especially on areas of overlap and integration
Problem solving can take place during these meetings
Teams decide who will represent them
Are you about to put something in another team’s way?

23. Demos
At the end of each Sprint, a demonstration is held, during which the team shows what they accomplished during the Sprint
The team presents the goal of the Sprint and demonstrates the features completed
The meeting is intentionally kept very informal
Slides/PowerPoint often not used or very limited
No more than 1-2 hours is spent in preparation
The audience is encouraged to ask questions and make comments
The outcome of the meeting is that stakeholders have seen working software presented by the people who did the work, can identify any changes needed, and can adjust the backlog as required for future Sprints

24. Retrospectives
At the heart of the Agile principles – inspect and adapt
Held at the end of each Sprint
Allows the team to inspect and adapt their processes
The goal of the retrospective is to identify what went well vs. what things should be changed
Repeat/Revise/Review
Repeat: “that worked great, let’s do it again”
Revise: “this caused difficulty, let’s do it different next time”
Review: “what if…; how about trying…?”
Show retrospective book

25. Metrics
Burn down
Velocity is a measure of a team’s rate of progress in points; used for tracking current and past sprints; can be used to estimate rate of progress for future sprints

26. Additional Resources Your Scrum Master Agile Commons
mountaingoatsoftware.com (especially for definitions)
Agile Austin monthly meetings
Agile Austin free workshops