Objectives

• Understand what Agile is and why we are doing it

• Scrum Framework
• Scrum Team and Roles
• Scrum Artifacts
• Scrum Events/Ceremonies
• Scrum Metrics
The Agile Mindset
As opposed to more traditional, sequential development methods, Agile methods allow us
and our organization to be responsive to what’s important.

In other words, Agile methods allow us to:

• Work on the most important things first.
• Embrace and manage change to be innovative and competitive while minimizing
unproductive churn.
• Focus on communicating directly with human beings.
• Be able to demonstrate working product or tangible services to stakeholders and
customers, rather than just talking about what will be done.

Respond to change in a predictive way, in order to deliver

results. The language we use and behaviors we exhibit with
each other effect our ability to deliver results.
Agile Manifesto – The Values
We are uncovering better ways of developing Software by doing it
and helping others do it. Through this work we have come to value:

Individuals and over

Processes and tools
interactions

Working software over

Comprehensive
documentation
Customer collaboration over Contract negotiation

? Responding to change over

Following a plan

That is, while there is value in the items on the right, we value
the items on the LEFT MORE.
Agile Values are Supported by 12 Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity - the art of maximizing the amount of work not done - is essential.

11. The best architects, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
SCRUM Framework
SCRUM Team

• We define “How” the work will be done

• We have the skills to deliver the project
• Self Organizing and Cross Functional
Development Team

• I decide “What” to do and

• I focus on how to work better
“Why”
• Keeper of the Scrum process
• Responsible for the product
• Works with stakeholders to
vision and delivering value Product Owner
Scrum Master remove obstacles and improve
• Manages product backlog
team velocity
SCRUM Team – Product Owner

Responsible for maximizing the value of the product resulting from work of the
Development Team.
Sole person responsible for managing the Product Backlog (is one person, not a
committee)
• Clearly expressing Product Backlog items
• Ordering the items in the Product Backlog to best achieve goals and missions
• Optimizing the value of the work the Development Team performs
• Ensuring Product Backlog is visible, transparent, understood, and clear to all

No one can force the Development Team to work from a

different set of requirements
SCRUM Team – Development Team

Individuals who do the work of delivering a potentially releasable Increment of the product.
• Are self-organizing
• Are cross-functional
• No titles for Development Team members
• No sub-teams in the Development Team

Individual Development Team members may have specialized skills and areas
of focus, but accountability belongs to the Development Team as a whole.
SCRUM Team – Scrum Master
Responsible for promoting and supporting Scrum by helping everyone understand Scrum
theory, practices, rules, and values. Serves the…
Product Owner Development Team Organization
• Ensuring that goals, • Coaching the • Leading and coaching
scope, and product Development Team in the organization in its
domain are understood self-organization and Scrum adoption
by everyone cross-functionality • Planning Scrum
• Finding techniques for • Helping the implementations within
effective Product Backlog Development Team to the organization
management create high-value • Causing change that
• Helping the Scrum Team products increases the
understand the need for • Removing impediments productivity of the
clear and concise to the Development Scrum Team
Product Backlog items Team’s progress
• Ensuring the Product • Facilitating Scrum events
Owner knows how to as requested or needed
arrange the Product
Backlog to maximize
value;
• Facilitating Scrum events
as requested or needed.
SCRUM Events
• To select PBI’s for the Sprint and create • To synchronize activities and create
a plan to realize them. a plan for the next 24 hours.

Sprint
Planning Daily Standup
Meeting

SPRINT

Sprint
Sprint Review
Retrospective

• For team to inspect itself and create •To demo product increment and
a plan for improvements. collect customer’s feedback.
SCRUM Events – Sprint Planning
Purpose: To plan the work to be performed in the Sprint
• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

Timebox: Eight hours for one-month Sprints

Attendees: Product Owner, Development Team, Scrum Master

Outcomes:
• Sprint Backlog
• Sprint Goal
SCRUM Events – Daily Scrum
Purpose: Key inspect and adapt meeting for the Development Team to plan work for the next 24 hours.
• 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?

Timebox: 15 minutes

Attendees: Development Team (Optional: Product Owner/Scrum Master)

Outcomes:
• Plan for the next 24 hours
• Improved communication
• Identification of impediments to development for removal
• Transparency and quick decision-making
SCRUM Events – Sprint Review
Purpose: To inspect the Increment and adapt the Product Backlog.
• The Product Owner explains what Product Backlog items have been completed
• The Development Team demonstrates the work that it has done
• The Product Owner discusses the Product Backlog as it stands and the Team collaborates on what
to do next

Timebox: Four hours for one-month Sprints

Attendees: Product Owner, Development Team, Scrum Master, Stakeholders

Outcomes: A revised Product Backlog that defines the probable Product Backlog items for the next
Sprint.
SCRUM Events – Sprint Retrospective
Purpose: Opportunity for the Scrum Team to inspect itself and create a plan for improvements to be
enacted during the next Sprint.
• 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
• Create a plan for implementing improvements to the way the Scrum Team does its work

Timebox: Three hours for one-month Sprints

Attendees: Product Owner, Development Team, Scrum Master

Outcomes: Identified improvements that it will be implemented in the next Sprint.

Although improvements may be implemented at any time, the Sprint Retrospective

provides a formal opportunity to focus on inspection and adaptation.
SCRUM Artifacts

• Owned by the • Owned by • One sentence • Shared • Sum of all the

Product Backlog

Sprint Backlog

Sprint Goal

Definition of Done

Increment
Product Owner development summary understanding of Product Backlog
• Single source of team • Defined by what it means items completed
requirements • Set of Product Product Owner for work to be during a Sprint
• Lists all features, Backlog items • Reviewed and completed and the value of
functions, selected for the accepted by • Owned by the the increments
enhancements Sprint team team of all previous
and fixes • Decomposed • Ensures Sprints
• Anybody can add task list for each transparency • Potentially
user stories user story shippable
• Prioritized by • Real-time picture version of the
business value of the work that product
• Can change the • Working
without affecting Development functionality
the active sprint Team plans to • Tested &
accomplish documented
during the Sprint according to the
• Only Definition of
development Done
team can update
Product Backlog

• A collection of high level requirements, represented by User

Stories, that will deliver the product vision and roadmap This Iteration

• Prioritized by the Product Owner with input from the team

Next
• The Product Backlog evolves over time, is never done, and is Iteration

Time / Priority
always ready
Future
• Created collaboratively and Elaborated “just in time” due to Stories
changes that may occur in this
Release
• There is always an active discussion among Product Owner and
team to better understand stories and requirements Future
Releases
User Stories
• High level definition of a requirement written in As an <actor>, I want to <feature/function>, so
plain English from the end user perspective that <value>

• A user story answers 3 important questions:

• Who are you building this for?
• What are you building? Examples:
• Why are you building this?
• Browse loyalty store items by theme
• Is a “promise for a future conversation” • Loyalty store items rating and reviews
• Immediately directs the focus to a specific • Customer Surveys
circumstance which provokes further discussion • Push notifications to encourage users to track
and careful revision. sessions
• Team becomes more focused on delivering • Data Backups
solutions to user problems as opposed to merely • Data Protection and Compliance
delivering functional code.
• Create user guide
User Stories - INVEST
A user should ideally have the following characteristics:

You should be able to prioritize and rearrange user stories in any way with no
overlap or confusion.

A good user story can be reworked or modified to best suit the business. User
stories are not an explicit set of tasks.

User stories need to be valuable - for the business or the customer.

A good user story can be estimated - rough estimate is beneficial to allow teams
to rank and schedule their priorities.

The larger a story is, the harder it is to estimate and easier it is to get caught up in
sub items that should have probably been their own stories.

It is essential that a criteria to test a user story is in place - ensures that the story
actually accomplishes its goal. A story is not finished until it is tested.
User Stories - Estimation
• User stories are estimated in Story
point instead of hours.
• Story points represent the relative sizing of the
user story.
• Factors to consider when estimating stories:
• Complexity: Consider the complexity of the story.
• Risk: Consider the team’s inexperience with
developing this story.
• Implementation: Consider the implementation
factors.
• Deployment: Consider the deployment
requirements.
• Interdependencies: Consider other outside issues.
User Stories - Estimation
• Story Point Estimation Techniques
• Planning Poker – using Fibonacci sequence
• T-Shirt sizing

• Who should be involved in Story Point

estimation?
Backlog Refinement

PB Refinement Refined
Product Backlog Product
Meeting
Backlog

Team meets to discuss PBI’s and

Anything and
breaks them into smaller ones. Also
everything required to
discusses estimates, acceptance
fulfill the product
criteria, definition of done and PBI
vision
prioritization.
Typical Sprint Calendar
Sunday Monday Tuesday Wednesday Thursday Friday Saturday

Sprint 1 Planning Daily Standup (15 Daily Standup (15

(4 Hrs) Mins) Mins)
Backlog Refine-
ment (2 Hrs)

Daily Standup (15 Daily Standup (15 Daily Standup (15 Daily Standup (15 Daily Standup (15
Mins) Mins) Mins) Mins) Mins)
Backlog Refine-
ment (2 Hrs)

Daily Standup (15 Sprint 1 Review Sprint 2 Planning Daily Standup (15 Daily Standup (15
Mins) (2 Hrs) (4 Hrs) Mins) Mins)
Backlog Refine-
Sprint 1 Retro ment (2 Hrs)
(1.5 Hrs)
SCRUM Metrics
Burndown
 Graphical representation of work remaining
versus time
 Extremely simple
 Tracks the amount of work remaining
across time
 Extremely powerful
 Provides clear project trending
 Provides rapid feedback when
adjustments are made
 Used at various levels
 Release burndown Chart
 Sprint burndown Chart
SCRUM Metrics
Team velocity
 The average number of story points the team is likely to complete in a sprint
 Powerful, yet simple measure for long term planning
 Important to keep the backlogs updated and current
 Important to have proper story point and effort estimation