1 Day Agile Essentials Refresher v1.2

Agile Essentials
Refresher
1 day Course
Instructor Introduction
Facilities, Logistics and Working Agreement
Restrooms
Emergency Exits
Sign in
Questions and Answers
Working Agreements
One problem you want solved?
or
One question answered in this course?
or
What would make you tell a co-worker or manager,
This was a great course!
Purpose
To provide you with knowledge and understanding of
fundamental Agile values, principles and practices
By explaining the benefits of Agile, introduce Agile best

practices and suggest some important things to consider
when embarking on being Agile
So that you deliver high value right things sooner while

focused on Customer Satisfaction, Employee Satisfaction,
Product Quality and Business Value
Course Objectives
Upon completion of this course, you will be able to:
Describe the Agile Scrum framework including its roles, artifacts, and Events,
as well as the principles that support it.
Produce working product using Scrum.
Determine how to define Done and how to use it on your team.
Describe the benefits of user stories and describe various sizing methods.
Track progress using visual management techniques.
Describe the 5 Levels of Agile Planning.
About You
Name
Role
Level of Agile Experience
Fist of Five Consensus Voting
5: Wild, unbridled support.
4: I think its a great idea. I wish I would have thought of it.
3: I can live with that and support it.
2: I have some reservations that Id like to talk about.
1: I am very opposed and we shouldnt move forward.
Lesson 1:
Introduction to Agile and Scrum
Module 1: Introduction to Agile
Module 2: Become Results-Oriented with Agile Values and Culture
Module 3: Agile Methods
Fundamental Paradigm Shift
TRADITIONAL DEVELOPMENT
Agile Process Is Quick and Efficient
Agile delivers a ready-to-ship feature every few weeks

Feature A Feature B Feature C Feature D
Potentially Potentially Potentially Potentially
Shippable Shippable Shippable Shippable
Agile
Analysis Analysis Analysis Analysis
Design Design Design Design
Code Code Code Code
Test Test Test Test
AGILE DEVELOPMENT TRADITIONAL DEVELOPMENT

What is Agile?
An empirical process that incorporates iteration and
continuous customer feedback to successively refine and
deliver a product.
Agile uses continuous planning, continuous testing, and

continuous integration.
Agile is lightweight, especially compared to traditional

waterfall-style processes, and designed to be inherently
adaptable to change.
Being Agile focuses on empowering people to collaborate and

make decisions together, quickly and effectively.
Ball Point Game
Lesson 1:
Module 2: Become Results-Oriented with Agile
Values and Culture
Values and Culture Values guide decision-making and a sense
of whats important and whats
right. Culture is the collection of business
practices, processes, and interactions that
make up the work environment
Practices
Values Culture
2015 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 16
The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, we value the items on the left more
Source: agilemanifesto.org
The 12 Agile Manifesto Principles
Satisfy the customer through early and continuous
1 delivery of valuable software.
Welcome changing requirements, even late in
2 development.
3 Deliver working software frequently.
Business people and developers work together daily

4 throughout the project.
5 Build projects around motivated individuals.
Face-to-face conversation is the most efficient and

6 effective method of conveying information.
The 12 Agile Manifesto Principles (cont.)
7 Working software is the primary measure of progress.
8 Agile processes promote sustainable development.
Continuous attention to technical excellence and

9 good design enhances agility.
10 Simplicity is essential.
The best architectures, requirements, and designs

11 emerge from self-organizing teams.
12 Reflect at regular intervals.

limit work-in-progress
Lesson 1:
Module 2: Become Results-Oriented with Agile Values and Culture
Agile Methods
Many frameworks and approaches fall under the Agile umbrella.
Lean Software Development
Scrum
eXtreme Programming
Kanban
Feature Driven Development
Dynamic System Development Method

Scrum
Scrum is a framework within which people can address complex adaptive problems,
while productively and creatively delivering products of the highest possible value.
Scrum is:
Lightweight
Simple to understand
Difficult to master
Scrum Values
SCRUM CORE
VALUES
Elements of Scrum
Defines potentially
shippable product
Product Backlog
Sprint Backlog Scrum
Potentially Shippable
Product Increment Team
Daily Scrum
Sprint Planning
Sprint Review
Sprint Retrospective
Development Team, Product
Owner, Scrum Master 2015 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 25
Large Scale Agile Scrum Frameworks
SAFe LeSS Nexus
Scrum at Enterprise
DAD
scale scrum
Scaling Agile
Lesson 2:
Developing a Working Product
Using Scrum
Module 1: Scrum Roles and Responsibilities
Module 2: Manage the Sprint Using Events
Module 3: Produce Working Products Using Scrum Artifacts
Module 4: Define Done
Elements of Scrum
Scrum
Team
Development Team, Product

Owner, Scrum Master 2015 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 29
Core Scrum Roles
Scrum Master Product Owner Development Team
Reinforces Agile Liaison between the Engineers; design,

values and practices development team build, test and
at the Development and Chief Product deliver shippable
Team level owner products based on
Supports the Collaborates closely Backlog items
Development Team with both groups to
with being fully ensure there is a
functional, clear understanding
productive, and of what features are
focused on the goal needed in the product
Complementary Roles to Scrum
Architect Functional Manager Agile Coach
Technical expert Supports Provides coaching to

Works with the Development Team the Development
Development Team to learn, grow, and Team by observing,
and Product Owner perform consulting, and
to ensure technical Removes obstacles providing feedback
alignment and for improvement
success of the
product
Scrum Master
Scrum Master
Servant Leader
Product Owner
Facilitates Development Team success
Development
Scrum Team
Master Facilitates continuous improvement
Architect
Facilitates team meetings and handles
logistics Functional
Manager
Tracks and communicates with outside
stakeholders Agile Coach
Scrum Master Characteristics
Scrum Master
Self-Motivated
Product Owner
Servant Leader
Passionate Scrum Advocate Development
Team
Common Sense Practitioner
Architect
Continuous Improvement Champion
Courageous and Respectful Functional
Manager
Agile Coach
Day in the Life of a Scrum Master
Scrum Master
How is my Product Owner doing?
Are Stories broken down to the appropriate level? Product Owner
Is there enough detail and/or acceptance criteria included?
Development
How is my team doing? Team
Do they have the information, tools, and support that they need to
meet the Sprint commitments? Architect
Do they have the details that they need from the Product Owner?
Functional
Manager
Agile Coach
See The Scrum Master Checklist by Michael James
http://www.Scrum Masterchecklist.org/pdf/Scrum Master_checklist09.pdf
Day in the Life of a Scrum Master (cont.)
Scrum Master
Information Radiators
Are Task Boards and/or electronic tools up-to-date with the latest Product Owner
information?
Do stakeholders have visibility to information? Development
Team
Engineering Practices
Is the team maturing in our engineering practices avoiding the Architect
accumulation of Technical Debt?
Are we continuously integrating to move to prevent defects as Functional
Manager
opposed to hunting for them at the end of the Sprint?
Agile Coach
See The Scrum Master Checklist by Michael James
http://www.Scrum Masterchecklist.org/pdf/Scrum Master_checklist09.pdf
Product Ownership
Chief
Product Owner
Scrum Master
Product Owner
Development
Team
Customer Architect
Functional
Development Manager
Team
Agile Coach
Product Owner
Role: Chief Product Owner
Communicates product vision from the highest levels of
executive leadership to development and implementation teams.
Investigates, selects, and drives the development of products for
an organization, performing the activities of product
management.
Considers numerous factors such as intended demographic, the
products offered by the competition, and how well the product
fits with the company's business model.
Product Owner
Remains engaged and responsive to Scrum Master
Development Team
Accepts/rejects Product Backlog Items Product Owner
using DoD & Acceptance Criteria
Development
Product Ensures the Product Backlog is visible, Team
Owner transparent, and clear to all

Architect
Team Backlog Owner Functional

Manager
Partners with and represents Chief
Agile Coach
Product Owner
Class Discussion: Product Owner
Timebox
What is the importance of the Product Owner role 8 Minutes
in the Scrum environment?
What is the most important responsibility for the
Product Owner to fulfill?
What is the most challenging aspect of being a
Product Owner?
Can the Product Owner be a Committee?
Development Team
Scrum Master
Product Owner
Development
Team
Architect
Functional
Manager
Agile Coach
Role: Development Team Responsibilities
Develop working product increments based on highest value
Product Backlog Items identified by Product Owner. Scrum Master
Attend and participate in all Scrum Events.

Product Owner
Size the work.
Development
Own the quality of the product and practice technical excellence Team
to enhance it.
Collaborate with Product Owner on Definition of Ready and Architect
Definition of Done.
Functional
Assist the Product Owner in maintaining the Product Backlog. Manager
Identify, attempt to resolve, and escalate obstacles in a timely Agile Coach

manner.
Role: Development Team Characteristics
3 to 7 People
Scrum Master
The Product Owner and Scrum Master are not included in the
Development Teams total capacity for getting stories done
unless they are also executing the work of the Sprint Backlog. Product Owner
Self-organizing Development
Team
100% dedicated
Cross-functional willing to take on any task that helps the team Architect
achieve Done
Functional
Self-motivated Manager
Collaborative Agile Coach

Courageous and respectful
Complementary Role: Architect
Scrum Master
Product Owner
A technical expert who works
with the Development Team Development
Team
and Product Owner to ensure
technical alignment and Architect
success of the product Functional

Manager
Agile Coach
Complementary Role: Architect Responsibilities
Tightly integrates with Development Team(s) Scrum Master
May be Development Team member

Product Owner
Collaborates with Product Owner to ensure a successful product
Development
Ensures implementation supports: Team
Testability
Automation Architect
Scalability
Functional
Performance Manager
Security
Extensibility Agile Coach
Supportability
Complementary Role: Architect Responsibilities
(cont.)
Scrum Master
Ensures that a customer solution view is brought to the code set
Product Owner
Continually provides technical mentoring to teams and
individuals
Development
Participates in Sprint Planning Team
Participates in Sprint Review Architect
Owns product architecture and technical product vision Functional

Manager
Agile Coach
Complementary Role: Functional Manager
Scrum Master
Obstacle ID and removal expert!
Product Owner
Embodies the values and culture
Development
Functional Team
Supports and plays by all Scrum rules"
Manager Architect
Tries new practices Functional

Manager
Great team member of the product
Agile Coach
leadership team
Responsibilities
Scrum Master
Actively supports Product Owners, Development Teams, and
Scrum Masters Product Owner
Supports Scrum Masters efforts to protect teams from
disturbance, disruption, or outside interference Development
Team
Promptly responds to escalations from Scrum Masters to help
remove impediments interfering with teams ability to get work Architect
done
Contributes to creating the right environment for Development Functional
Teams to be successful Manager
Agile Coach
Responsibilities (cont.)
Scrum Master
When requested by Development Team or as appropriate,
provides advice and assistance to Development Teams on Product Owner
architectural direction and resolution of technical challenges
Understands and communicates company strategy, direction, Development
Team
initiatives, and portfolio roadmaps
Understands the broad community of stakeholders that are Architect
affected by our company and products, including competitors,
customers, analysts Functional
Manager
Agile Coach
Functional Manager Impediment Backlog
Scrum Master
A key part of an Functional Managers responsibility is removing
organizational impediments. Product Owner
An impediment is anything that represents a threat to the team

Development
achieving its commitment. Team
Managers can serve the team by removing these barriers.
Architect
Managers can also help the team continue to evolve by
teaching them how to resolve organizational barriers. Functional
Manager
As the team grows, they should be able to independently
resolve more of the impediments. Agile Coach
Functional Manager Behaviors to Avoid
Scrum Master
Decide what work needs to be done.
Assign the work to team members. Product Owner
Keep track of what everyone on the team is doing. Development

Team
Make sure the team gets their work done.
Make commitments to management about how much the team can do Architect
by a certain date.
Make commitments to management for the team. Functional
Manager
Request individual weekly status updates.
Agile Coach
Turn Scrum Masters into mini-managers.
Complementary Role: Agile Coach
Scrum Master
Product Owner
Observing
Development
Team
Architect
Providing
Consulting Functional
Feedback Manager
Agile Coach
An Agile Coach
Does Does Not Scrum Master
Guide and facilitate Direct or drive
Keep everyone focused on Stick to deadlines and Product Owner
delivering business value approaches that no longer work
Development
Have a keen interest in the Become attached to specific Team
teams overall performance outcomes from the team
Architect
Coach the team for high Get involved in task level
performance direction Functional
Promote the skills and growth of Become the only voice of the Manager
every team member team

Agile Coach
Reference: Coaching Agile Teams, Lyssa Adkins; Addison Wesley, 2010.
Lesson 2:
Using the Elements of Scrum
Elements of Scrum
Scrum
Team
Daily Scrum
Sprint Planning
Sprint Review
Sprint Retrospective
Standard Sprint Cycle
PO Product Owner
SM Scrum Master
T Team
C Customer
Product Backlog
Refinement
Input from 24
End-Users,
Customers,
hrs Daily
Team and Sprint Scrum
Other Review
Stakeholders
Product
Sprint
Product
Retrospective
Sprint Owner
Owner
1-4 weeks
Potentially Incremental
Sprint Backlog Shippable Product Product Release
Product Backlog Sprint (Stories, slices of
(Features)
Increment
Planning functionality)
The Sprint Planning Event
PO Product Owner
SM Scrum Master
T Team
C Customer
Product Backlog
Refinement
Input from 24
End-Users,
Customers,
hrs Daily
Other Review
Stakeholders
Product
Sprint
Product
Retrospective
Sprint Owner
Owner
1 4 weeks
(Features)
Increment
Event: Sprint Planning Parts
Part I Part II
Determine what Product Backlog Determine how the work will be
items will be completed in the completed in the Sprint by the Team
Sprint by the Team (the Goal) (the Tasks)
The Product Owner sets priority,
answers Definition of Done questions,
and works with the Team to establish
the Sprint Goal based on the Teams
Velocity
The Team breaks the PBIs down into
tasks, sizing them in Hours
The Scrum Master facilitates keeping
the meeting moving and ensuring that
the Scrum framework is being followed
Event: Sprint Planning Timebox
Sprint Planning is meant to be a brief Event for the team to

authentically forecast the Product Backlog Items without overloading
their bucket
This session has a rule of thumb that says the session should be 2
hours or less for every 1 week of the Sprint:
1 Week Sprint = 2 Hour Sprint Planning or Less
Event: Sprint Planning Agenda
Topic Responsible Party
P.O. Intro/Review Agile Charts Product Owner/Scrum Master
Defect Triage (if needed) Product Owner
Determine team capacity Development Team
Teams verify pre-fetching is still valid. Any horse
Development Team/Product Owner
trades needed?
Set a time for touch-point to meet again after
Development Team
planning
Plan/Task Development Team
Have touch-point after planning for each team to
give a summary:
What Product Backlog Items/User Stories were
Development Team
planned?
What tests will be used for each one?
Call out any inter-team dependencies
The Daily Scrum Event
PO Product Owner
SM Scrum Master
T Team
C Customer
Product Backlog
Refinement
Input from 24
End-Users,
Customers,
hrs Daily
Other Review
Stakeholders
Product
Sprint
Product
Retrospective
Sprint Owner
Owner
1-4 weeks
(Features)
Increment
Event: Daily Scrum Meeting
Inspect and adapt mechanism for the team

Meet at the Scrum Board
This Event is NOT a status report to the Scrum Master, a problem-
solving session, or an executive forum
Three questions:
- What did I do yesterday that helped the team meet the Sprint Goal?
- What will I do today to help the team meet the Sprint Goal?
- Do I see any impediment that prevents me or the team from meeting the
Sprint Goal?
The Sprint Review Event
PO Product Owner
SM Scrum Master
T Team
C Customer
Product Backlog
Refinement
Input from 24
End-Users,
Customers,
hrs Daily
Other Review
Stakeholders
Product
Sprint
Product
Retrospective
Sprint Owner
Owner
1-4 weeks
(Features)
Increment
Event: Sprint Review
Opportunity for customers and other stakeholders to see the building blocks
of their project come to life
The Sprint team should not spend the last days of their Sprint preparing for
the Review; prep time should be kept to a minimum
Purpose is to be a raw demonstration of working software, such as a
demonstration of one or two of the key test scenarios within the working
system
Event: Sprint Review Best Practices
Invite one customer per feature.
The Scrum Master facilitates the Event.
Feedback received is added to the Product Backlog.
If TAC is joining your Sprint demo, ask TAC to keep questions until the end
when customers drop off.
At the end of the demo, ask TAC to share any comments/questions to the
engineering teams.
Ask someone besides the PO or SM to take the meeting minutes.
Class Discussion: Sprint Review
Timebox
What happens if attendees do not participate in the 8 Minutes
Sprint Review?
What happens if attendees insist on the Development
Team addressing their feedback immediately?
What happens if the Sprint Review is poorly attended?
What if the Product Owner is overruled by the Sprint
Review attendees?
The Sprint Retrospective Event
PO Product Owner
SM Scrum Master
T Team
C Customer
Product Backlog
Refinement
Input from 24
End-Users,
Customers,
hrs Daily
Other Review
Stakeholders
Product
Sprint
Product
Retrospective
Sprint Owner
Owner
1-4 weeks
(Features)
Increment
Event: Sprint Retrospective
Inspect and adapt mechanism for the team to make adjustments to their
process or how they do work for the next Sprint
Celebrate successes in addition to examining what did not go so well
Team decides which items from their brainstormed list to put into action for
the next Sprint
Several approaches for facilitating this session are shared by Esther Derby
and Diana Larsen in Agile Retrospectives
Event: Sprint Retrospective Agenda
1. Set the Stage

2. Gather Data
3. Generate Insights
4. Decide What to Do
5. Close the Retrospective
Reference: Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen, 2006.
Event: Sprint Retrospective (cont.)
What Went Well? What did Not Go so Well?
Celebrate good team behavior Identify impediments to the
Teams performance
Recognize simple but effective
things Were there any attempts to
improve that failed?
Focus on the Team and the
process, not the Product Try to focus on those items
within the Teams control dont
dwell on external factors
Key Question: What will we Improve Based on the Discussion?

Lesson 2:
Module 3: Produce Working Products Using Scrum
Artifacts
Elements of Scrum
Product Backlog
Sprint Backlog Scrum
Potentially Shippable
Product Increment Team
Core Scrum Artifacts
Product Backlog Sprint Backlog Potentially Shippable
Product Increment
An ordered list of The work items A product increment
work may comprise selected from the that could be shipped
the product Product Backlog, or deployed to actual
along with the tasks users
necessary to get them
to Done, that the
Development Team is
forecast to complete
in the current Sprint
Product Backlog
The product backlog is a ordered list of

work items for a shippable product...
...and is the single source of

requirements for any work to be done
by the Development Team
Product Backlog Items
Item Size
Features
Product backlog Technical work

items (PBIs)
Knowledge acquisition
PBIs ordered based on value to

customer and feature dependencies!!
Ordering the Product Backlog
Value to Customer Order in Backlog
Product Backlog Refinement
PO Product Owner
SM Scrum Master
T Team
C Customer
Product Backlog
Refinement
Input from 24
End-Users,
Customers,
hrs Daily
Other Review
Stakeholders
Product
Sprint
Product
Retrospective
Sprint Owner
Owner
1-4 weeks
(Features)
Increment
Purpose of Product Backlog Refinement
To identify and create new Product
Backlog Items
To add detail to existing Product Backlog
Items
To split large Product Backlog Items into
right-sized Product Backlog Items
To validate and update priorities
To prepare for Sprint Planning
To prepare for releases
Product Backlog Refinement
Product Owner is continuously refining the Backlog to ensure it is always a
current snapshot in time
Scrum Master can assist the Product Owner
For sessions that require more external inputs, a session can be scheduled
that includes any or all of the following roles:
Business Analystskilled team member
Technical-skilled team member
Quality Assuranceskilled team member
Key stakeholder(s)
Product Backlog Refinement: A Definition of
Ready
In order to ensure that Product Backlog Items are ready to be developed by
the Development Team, some teams establish a Definition of Ready
A Product Backlog Item is Ready when it is:
Testable
Feasible (It can be completed in a single Sprint)
Understood by both the Development Team and the Product Owner
Having a Definition of Ready can help a team determine when they have
refined a particular Product Backlog Item enough so that it can be consumed
by the Development Team in the Sprint.
Product Backlog Refinement: The Impact of
Unrefined Backlog
Poor Backlog
Not enough Stories ready for the Sprint
Lack of details causing argument and indecision in tasks
Inability to determine if a Story is done or not
Release that cannot be forecasted

Not enough right-sized Stories available to the Development Team to be estimated
Continuous drastic shifts in priorities
No priorities
Current Backlog that is not available to those who need it most

Information should be updated into the Backlog quickly to ensure it is accessible in
real time for everyone at anytime
The Sprint Backlog
Most highly valued Product Backlog Items broken down

into Tasks
Created and maintained by the Development Team
Represents the Team commitment to the Product Owner
Task
Product
Backlog Item
Task
Potentially Shippable Product Increment
A slice of valuable functionality that can potentially be

shipped or deployed to users
The goal of each Sprint
Must provide business value
Demonstrated at the end of each Sprint in the Sprint
Review
Lesson 2:
Elements of Scrum
Defines potentially
shippable product
Scrum
Team
What Is Done?
The team's quality statement for a user story
or feature
Defines "potentially A statement that no more work is left to be
shippable product" done on this piece of functionality, it works
without errors, and is ready for release
to market
A set of criteria defined and approved by

All the things
leadership team
you need to do
The work, the approach, the workmanship
before you
release product
to customers
Benefits of Defining Done
Ensures a feature is 100% developed and tested
Obstacles are made visible and clarified by it
Velocity cannot be accurately estimated without it
Prevents accumulation of technical debt!!
Tips for Successfully Using Done
Visually represent Done as a checklist that everyone on the team fully
understands.
The entire team needs to commit to Done.
Align Done with Quality and Test Strategy.
Done is a living document that is strictly followed and continually widened.
Have a rigorous exception process only if necessary.
Example: Definition of Done
Standard Sprint
User story is complete Externaldocumentation complete,
Automated Unit test, code technically reviewed, tested, and
coverage, code review & revisions checked into a source code control
complete system
Product owner demo accepted Project Architect reviews design per
feature
User story has no open defects
TOIdevelopment complete per
Staticanalysis is at 100% pass
feature/epic story as applicable
rate on code developed in the
sprint
Example: Definition of Done
Standard Sprint (cont.)
Test
cases documented and test Featurerunning on acceptance test
case results tracked in TIMS bed (deployment model)
Load, performance, and scalability Internationalized and has passed
testing completed I18n tests
Featuretest 100% automated & Risk
to ship reviewed and approved
100% pass rate (Positive and by QA
Negative) Test
case(s) reviewed by
Development Team and approved by
QA
Can't Fit It All in Story or Sprint Done?
Mix in Release Done along the way so you don't build up a huge debt to complete in the final Release
Done
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11
Story Story Story Release Story Story Story Release Story Story Release
Done Done Done Done Done Done Done Done Done Done Done
with
Release
to Market
For example: Performance

& Solution testing might go
here
Multiple Definitions of Done
Lesson 3:
Writing and Estimating Effort
Using User Stories
Module 1: Introduction to Writing and Managing User
Stories
Module 2: Estimate Project Effort by Sizing User Stories
What Is a User Story?
A concise, written description of a

piece of functionality that will be
valuable to a user (or owner) of the
software
The beginning of the conversation
not the end
Why Use User Stories?
Convey a customers goal to developers in terms that focus on

expressing business value
Give clarity as to why a feature is useful
Can influence how a feature should function
Can give you ideas for other useful features that support the user's
goals
What Do User Stories Look Like?
Tips:
Who [user role] Keep yourself expressing business value
Avoid introducing detail too early that
What [goal] would prevent design options and
inappropriately lock developers into one
solution
Why [value] Avoid the appearance of false
completeness and clarity
Get to small enough chunks that invite
negotiation and movement in the backlog
Leave the technical functions to the
architect, developers, testers, etc.
Acceptance Criteria
Acceptance criteria represent the conditions that must be met in order

for the Product Owner to accept the User Story.
As details about the story evolve during refinement, capture the
critical ones as acceptance criteria.
The team should have a conversation about the acceptance criteria,
and adjust them to capture the results of the discussion.
Once a Sprint has begun, testers can formalize acceptance criteria
into acceptance tests.
Example: Acceptance Criteria
User Story Done Example
As a customer I want to be Code complete and 0 bugs
able to pay for my stuff by Passed unit tests, functional, system, load,
VISA card so that duration, usability, and negative tests
Complexity refactoring completed
Code peer reviewed and all QA standards met
Relevant documentation updated
Acceptance Criteria Example

I can purchase "stuff" by VISA card
I cannot pay with a VISA card that's expired
I cannot pay with a VISA card with a wrong
number
INVEST in Good User Stories
I ndependent
N egotiable
V aluable
E stimatable
S mall
T estable
Reference: Invest in Good Stories and Smart Tasks
Bill Wake, August 17, 2003.
User Stories versus Epics
Product A large story; often too
Backlog big to fit into one Sprint
Epic Epic Epic
Story Story Story Story Story Story
Ideally coded and tested in just

a few days; fits into one Sprint
Example: Breaking Epics into Stories
As an Inventory Analyst
I can run inventory reports
so that I can determine and manage
inventory levels
As an Inventory Analyst As an Inventory Analyst As an Inventory Analyst

I can run an inventory report by I can run an inventory report by I can run an inventory report by
store district region
so that I can view the inventory so that I can view the inventory so that I can view the inventory
available at each store. available in each district. available in each region.
Class Exercise: Writing User Stories
Timebox
In your Teams, create a Product Backlog 20 Minutes
Use sticky notes or index cards to
capture your Product Backlog items
Each story should contain at least one
condition of acceptance
Do not worry about ordering or
estimation
Lesson 3:
Writing and Estimating Effort
Using User Stories
Module 1: Introduction to Writing and Managing User Stories
Module 2: Estimate Project Effort by Sizing User
Stories
What Is Story Sizing?
Story sizing IS...
Determining the relative complexity of user stories
Story sizing is NOT...
A detailed schedule of work
Based on the length of time required to complete
Measured in absolute terms!!

Why Story Sizing?
Release and Sprint Planning
How many stories can we do in this Sprint?
How many stories/epics can we do in this release?
Story Points
Story Point Characteristics
Empirical
Relative
Unit-less
Less granular the larger they get
Velocity Characteristics
Sum of story point for completed stories within a Sprint
Used for estimating, NOT tracking
NOT a productivity measure
The Fibonacci Scale for Ranking
Estimating via the Fibonacci Scale

Each number is sum of the previous two (1, 2,
3, 5, 8, 13, etc.).
Estimating precision decreases the larger the
story.
A 13 often indicates the story is too big. Try to
break it into smaller stories.
Story Sizing Method: Planning Poker
1 Discuss
Product
Backlog Item
3 2
Hear from the Outliers Vote
4
Reach consensus
Planning Poker is a registered Trademark of

Mike Cohn and Mountain Goat Software
Class Exercise: Estimation #1
Timebox
Select one team member to be the facilitator this person 5 Minutes
does not estimate card sizes
Individual Placement do this silently
Each team member takes a turn by placing a card
If it is bigger than cards already placed, set it on the right
If it is smaller than cards already placed, set it on the left
If it is the same size as card(s) already placed, set it underneath
You may choose to move a card instead of place a new one
If a particular card is getting moved a lot, the facilitator moves it
to the parking lot for later consideration
Class Exercise: Estimation #2
Timebox
Select a different team member to be the facilitator this 7 Minutes
person does not estimate card sizes
Team Placement you may talk if you would like
Each team member takes a turn by placing a card
If it is bigger than cards already placed, set it on the right
If it is smaller than cards already placed, set it on the left
If it is the same size as card(s) already placed, set it underneath
You may choose to move a card instead of place a new one
If a particular card is getting moved a lot, the facilitator moves it
to the parking lot for later consideration
Lesson 4:
Implementing Scrum
Module 1: Track Progress Using Visual Management
Tools
Visual Management Tools
Velocity Chart Release Burn Up Sprint Burndown
Chart that measures daily Chart that tracks progress Chart that tracks remaining
velocity of the team to deliver toward the completion of work vs. time
shippable product work
Obstacle Boards Scrum Board
Boards that track obstacles Physical board that displays

that slow the team down product backlog items, task
progress, team obstacles,
team artifacts, Sprint
Burndown chart, and team
availability for Sprint
Burndown Chart
Release Burn-Up Chart
Points
Product scope (refined as
Release Burn-Up
10,000
work progresses)
8,000
6,000
4,000
Projected
Accepted Points Completion Date (of
2,000
product, not Sprint)
0
10/11
10/25
11/08
11/22
12/06
12/20
6/21
7/05
7/19
8/02
8/16
8/30
9/13
9/27
1/03
1/17
1/31
2/14
2/28
3/14
3/28
4/11
4/25
5/09
5/23
6/06
6/20
Earned points Scope points Target eLib Project trend eLib
Velocity Chart Sprint
Points Velocity and Capacity Last 3 Sprint Avg.: 284 point
600
500
Sprint Capacity
Estimate
Not Accepted
400 152
136 207
Points 86
100 174
49
165 109
145 131 169 126 132
74 181
300 130 63
57 197
130
200 105
99 26
83 333 325
76 296 308 305
288 277 272 272 287
264 255 268 260 264 261
63 91 240 239
47 224 217
100 198
167 153
128 113 118
89 91
Accepted Points
77
0
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Not accepted points Accepted points Point capacity estimate Linear (Velocity)
Class Exercise: Sprint Burndowns
Lesson 5:
Planning
Module 1: 5 of Levels Planning
Module 2: Multi-Sprint Planning
Module 3: Sprint Planning
Module 4: Velocity
5 Levels of Planning
Strategic
DPL
Release/
Multi-Sprint
Sprint
Daily
The Vision needs to...
1. Inspire
2. Capture the imagination
3. Be easy to share
4. Get people excited
Charter and Vision
Its not the artifact,

its the charterING
and the visionING
not aiming
but steering
What is Strategic Planning?
A focus on business value driven by three investment types

A planning process to prioritize and capacity plan large multi-quarter
Strategic Items that encapsulate Ciscos Vision
It reflects multiple quarters of work across Product Lines and PINs
Planning is done at a high level, so a degree of uncertainty is inherent
Directly linked to lower level portfolio items (e.g. DPL & Features)
which drives our release planning
CSG Strategy drives Portfolio Strategy
Focused on Business Value

- Portfolio-based thinking shifts from the traditional cost-only model to one
emphasizing business value where we seize opportunities to gain competitive
advantage, even going so far as to fundamentally alter our industries rules.
Investments in product innovation are prized.
- IT investments must be assessed through a lens of well-defined prioritization so that

top-line potential is optimized based on categorized portfolio-based thinking where IT
investments are grouped into three investment types:
Run the business
Grow the business
Transform the business
Product Management Focus
Engineering Focus R
E
Release/ L
Strategic DPL Sprint
PIN Vision
Planning Planning
Multi-Sprint Planning
Development E
Planning
A
S
E
Roadmap
June September December
Release1 Release2 Release3

Agile Release/Multi-Sprint Planning
Sprint 1 Sprint 2 Sprint 3
Sprint Sprint Sprint Product

Increment
Product
Product Product
Backlog Increment Increment
Lesson 5:
Planning
Module 1: 5 Levels of Planning
Module 4: Velocity
Product Backlog
Multi-Sprint Planning Story

As a I want toSo that..
Size
3
Deriving Cost, Schedule and Scope As a I want toSo that.. 8
As a I want toSo that.. 2
How many sprints will it take to As a I want toSo that.. 8
complete the Product As a I want toSo that.. 2
Backlog? As a I want toSo that..
2
12
What is the timeline to As a I want toSo that.. 3
complete? As a I want toSo that.. 2
What is the cost if a two-week As a I want toSo that.. 8
sprint has a total resource rate As a I want toSo that.. 8
of $30,000? As a I want toSo that..
20
20
Multi-Sprint Planning Agenda
PO presents goals for release and priority backlog items
Review current development state
Present release schedule
Discuss issues and concerns
TEAMS: (size backlog items and) put stories into iterations
Walk the walls (review plans for all teams)
Adjust plan including dependencies and assumptions
Commit to plan
Define communication plan
Retrospect
Bring All Players Together
Radiating Dependencies between Teams
Lesson 5:
Planning
Module 4: Velocity
Sprint Planning
Product Sprint
Backlog Backlog
Product Owner Owns the Backlog
When there is a disagreement to the sequence,

the Product Owner wins. Every time.
However, it is up to the development team to

provide information (assumptions, constraints,
alternatives) to the Product Owner in order to help
her prioritize the backlog items.
Mike Cohn, User Stories Applied
Lesson 5:
Planning
Module 4: Velocity
Velocity
A long-term measure of the amount of work
accepted per Sprint
Story Points Completed 35
30
25
20
15
10
5
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Calculating Velocity
Sprint One
Story 1 Story 3
Team
5 8
commits to: Points2 Points
Story
Story 4
8 3 Point
Points
=
24 points
Calculating Velocity
Sprint One
Story 1 Story 3
Product
5 8
Owner Points2 Points
Story
accepts: 8 Story 4
3 Point
Points
=
16 points
Team Velocity for Sprint 2

More Reliable Planning
5 Levels Agile Planning CSG Portfolio Hierarchy
Strategic Item
Strategic
DPL Development
Priority List
Release/
Multi-Sprint Feature
Sprint
Engineering
Feature
Daily User Story
Task
Parking Lot and Questions
Thank you for your time!
Theres never been a better time to innovate with Agility

1 Day Agile Essentials Refresher v1.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 Day Agile Essentials Refresher v1.2

Uploaded by

Copyright:

Available Formats

Agile Essentials

By explaining the benefits of Agile, introduce Agile best

So that you deliver high value right things sooner while

Agile delivers a ready-to-ship feature every few weeks

AGILE DEVELOPMENT TRADITIONAL DEVELOPMENT

Agile uses continuous planning, continuous testing, and

Agile is lightweight, especially compared to traditional

Being Agile focuses on empowering people to collaborate and

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

3 Deliver working software frequently.

Business people and developers work together daily

5 Build projects around motivated individuals.

Face-to-face conversation is the most efficient and

8 Agile processes promote sustainable development.

Continuous attention to technical excellence and

The best architectures, requirements, and designs

12 Reflect at regular intervals.

Feature Driven Development

Dynamic System Development Method

SAFe LeSS Nexus

Development Team, Product

Reinforces Agile Liaison between the Engineers; design,

Technical expert Supports Provides coaching to

Owner transparent, and clear to all

Team Backlog Owner Functional

Attend and participate in all Scrum Events.

Identify, attempt to resolve, and escalate obstacles in a timely Agile Coach

Collaborative Agile Coach

success of the product Functional

May be Development Team member

Participates in Sprint Review Architect

Owns product architecture and technical product vision Functional

Tries new practices Functional

An impediment is anything that represents a threat to the team

Keep track of what everyone on the team is doing. Development

every team member team

Sprint Planning is meant to be a brief Event for the team to

Inspect and adapt mechanism for the team

1. Set the Stage

Key Question: What will we Improve Based on the Discussion?

The product backlog is a ordered list of

...and is the single source of

Product backlog Technical work

PBIs ordered based on value to

Release that cannot be forecasted

Current Backlog that is not available to those who need it most

Most highly valued Product Backlog Items broken down

A slice of valuable functionality that can potentially be

A set of criteria defined and approved by

Ensures a feature is 100% developed and tested

Obstacles are made visible and clarified by it

Velocity cannot be accurately estimated without it

Prevents accumulation of technical debt!!

For example: Performance

A concise, written description of a

Convey a customers goal to developers in terms that focus on

Acceptance criteria represent the conditions that must be met in order

Acceptance Criteria Example

Epic Epic Epic

Story Story Story Story Story Story

Ideally coded and tested in just