Team training

1. 1
Agile
for
Scrum Team Members

2. 2
Working Agreements

3. 3
Course Requirements
Description
• In this course, we will discuss the skills necessary to work as an effective agile team and how to
transition from a sequential work style to a swarming work style.
• Self-organized cross-functional teams are the cornerstone of agile development.
Prerequisite
• Prior to taking this training, you should have completed the following:
• Agile 101 Training
Intended Audience
• Developer, Tester, Technical Leader, QA Leader, Architect, Business/Service Analyst
• Any leadership role involved in Product/Service Planning & Delivery process e.g. Technical Managers,
QA Managers, Project Managers, Program Managers

4. 4
Agenda
Agile and Scrum Flow – A Recap
Agile for Teams2
Lean Thinking with Ball Point Gamea
Sizing, Estimating and Prioritizing Backlogc
Definition of Ready, Definition of Doned
Agile Engineering Principlese
1
Scrum Team Member- New Expectationsb

5. 5
Agile Scrum Team Videos
Team Level video:
The Wrong way to do Agile: Team Structure
Planning video:
The Wrong way to do Agile: Planning
Demo video-
How to: Improve sprint reviews
Standup video:
The Wrong way to do Agile: Stand-ups
Retro video-
The Wrong way to do Agile: Retrospectives
Specifications video:
The Wrong way to do Agile: Specifications

6. 6
What are Lean Principles? And How do we implement them in Agile
Lean Principles Implementation in Agile
Eliminate waste Retrospectives, Feedback loops at every iteration
Amplify learning Retrospectives, Feedback loops at every iteration
Decide as late as possible Iteration Planning every 2 weeks
Deliver as fast as possible Short Iterations
Empower the team Servant Leadership, Team Collaboration
Build integrity in Build Quality In: Continuous Testing & integration
See the whole Cross functional teams, breaking down Silos
Principles
Values
Process
Practices
(kata)

7. 7
Scrum Framework: Process, Artifacts and Events
24h
SPRINT
POTENTIALLY
SHIPPABLE
INCREMENT
SERVICE & PRODUCT
ADOPTION BACKLOG
SPRINT BACKLOG
SPRINT DEMO
SPRINT RETROSPECTIVE

8. 8
Agenda
Agile and Scrum Flow – A Recap
Agile for Teams2
Lean Thinking with Ball Point Gamea
Sizing, Estimating and Prioritizing Backlogc
Definition of Ready, Definition of Doned
Agile Engineering Principlese
1
Scrum Team Member- New Expectationsb

9. 9
Team Building Activity: Lean Thinking with Ball Point Game
Objective:
Get as many balls “flow” through the team as possible within 2 minutes
Rules:
1. Each ball must have air-time.
2. Each ball must be touched at least once by every team member.
3. Balls cannot be passed to your direct neighbor to your immediate left or right.
4. Each ball must return to the same person who introduced it into the system.
5. There are a total of five iterations.
6. A designated timekeeper records count of balls passed during each iteration.
Instructions: 5-minute short iteration, 5 such iterations
1. Two minutes of preparation time to determine how team will self-organize. (~Planning)
2. Two minute game play. (~Sprinting)
3. Record #balls that pass through the system (~Demo)
4. One minute to discuss how to improve the process. (~Retrospective)
5. Repeat for five iterations (steps 1 to 5).

10. 10
SCRUM - Team
SERVICE OWNER
A person responsible for
maximizing the value of the
Service and the work of the
Scrum Team (Service Backlog
and determination of
priorities)
SCRUM TEAM
Professionals who do the work for
delivering a potentially releasable
Increment of “Done“ software at the
end of each Sprint. The software is
coded and tested. Self-organizing,
cross-functional
SCRUM MASTER
A person ensuring that Scrum is understood
and enacted. Expert in the Scrum Process and
monitors the Scrum Team progress
PRODUCT OWNER
A person responsible for
ensuring Product adoption of
the Service and maximizing
the value of the Product
(Product-specific Backlog and
determination of priorities)
SUPPORTING SMEs
Professionals who work on the
enabling elements of a Service
and/or Product Adoption
SERVICE ANALYST
A person who defines Service
Level Requirements, Use Cases
and User Stories.
Supports UAT.
BUSINESS ANALYST
A person who defines Product
Adoption Level Requirements,
Use Cases and User Stories.
Supports UAT.
AGILE COACH
A person leading and coaching the
organization in its Agile and Scrum
adoption.
PROGRAM MANAGER
(SERVICE AND PRODUCT)
A person who manages and resolve
Interdependencies and aligns
enabling activities to support team.
Also involved in monitoring and
tracking of velocity and other health
indicators

11. 11
Mindset Shift: Agile Team Members Collaborate with each other, Business and Operations
From Order-taking mindset:
Fulfilling orders only as requested by business
and not clarifying and consulting on needs
To Collaboration mindset:
Proactively bringing Business and Operations to
jointly do problem solving on issues & solutions
From Command-and-Control Culture:
“Our role is to execute on what is given to us
without judgement”
To Culture of Collaboration:
“Our role is to consult with other teams &
business to understand needs & concerns”
From Being Specialist only:
“Our roles are precisely defined, and if it’s not
in my job description, it’s not my responsibility”
To Becoming Specializing Generalist:
“Gray areas in role and org definitions are an
opportunity for flexibility and growth”

12. 12
Mindset Shift: Interaction Continuum
Non-Cooperation
Cooperation
Collaboration
• I’m not going to do that. You are not part of my department, so I couldn’t care less
what you need
• “Not my job”
• 1 – 1 = 0
• I will do it, but only if you work through the contractually agreed cooperating
model between us. I’m still mainly concerned with my piece of the puzzle
• “When something doesn’t work, we need to find out who is at fault”
• 1 + 1 = 2
• We exchange relevant information in support of each others goals, building off
each others strengths to create something beyond our own individual abilities
• “We’re all in it together”
• 1 + 1 = 3
Where are we at on this continuum? Where do we want to be?

13. 13
Break #1

14. 14
Agenda
Agile and Scrum Flow – A Recap
Agile for Teams2
Lean Thinking with Ball Point Gamea
Sizing, Estimating and Prioritizing Backlogc
Definition of Ready, Definition of Doned
Agile Engineering Principlese
1
Scrum Team Member- New Expectationsb

15. 15
User Story Map: Begin With End In Mind
• Release Planning
starts with User Story
Mapping
• Align stories as per
user activity (2nd line)–
helps with grouping
the features (1st line)
toward the activity
• High value items at
the top and low value
items at the bottom
• Stories
(Product/Service
Backlog) categorized
by Releases
(Release Backlog)
• Incrementally realize
the Product Goals
optionality
necessary
less
optional
more
optional
Release 1
Release 2
Release 3

16. 16
User Story map Exercise
• Identify an Epic from your current engagement (1 per group)
• Create a user story map for 1 or 2 personas

17. 17
Break #2

18. 18
User Stories creation
“As a <role>, I want <goal>, so that <benefit>”
User stories provide a different communication strategy than
traditional requirements, telling us WHO wants WHAT and WHY:

19. 19
I N V E S T
Independent Negotiable Valuable Estimable Small Testable
- Make
stories as
independent
as possible
from each
other
- Start with a
brief
description
- Details
emerge in
discussion &
negotiations
- Users and
customers
perceive
value in the
deliverables
- Domain and
technical
knowledge
allow the
team to
provide
estimates
- A team can
finish one
story in a few
days, and
several in
every sprint
- Acceptance
(testing)
criteria and
technique are
specified
clearly
Summary: Invest in Writing Good User stories

20. 20
Life Cycle of a User Story
Product/Service Owner PO + ARCH + LEAD PO + QA + LEAD PO + Team
Product/Service Owner
writes epics that are
negotiable and has
relevant business value
Architect and Team Lead
negotiate with PO/ SO to
create vertical slices of
epics to shape small and
independent stories
QA ensures stories are
testable and estimable
with scenarios for each
user story
Additional story split along
scenarios and acceptance
criteria may occur
Team receives well
packaged user stories
Team negotiates user
stories with the
Product/Service Owner
Team sizes story for
understanding and
provides estimate
Negotiable
Valuable
Independent
Small
Estimable
Testable

21. 21
Exercise #2: Decompose Epic into User Stories from Story Map (Template)
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
Participate in user story grooming session to write 3 user stories from your Story Map
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:

22. 22
Exercise #2: Decompose Epic “Send Money Using Mobile Devices” (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff

23. 23
Exercise #3: Refining User Stories with BDD template (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Apple as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Square as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. GIVEN PayPal as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff

24. 24
Why Team-Based Estimation: Overview
Can we Estimate Size of cars?
Pretend you and your team are looking out a
window at a parking lot and are tasked with
estimating the size of the cars.
Relative Easier than Absolute
•Toyota Corolla in the foreground is a small car
•The Ford Excursion is neither small nor large,
yet looks smaller to team based on distance
Team Eliminates any Bias
Team can discuss and eliminate the bias that the
distance causes to come up with a more correct
way by doing relative sizing of the two vehicles.
Ford Excursion
Toyota Corolla

25. 25
Why Team-Based Estimation: With Sizing Board
• Increases accuracy by including all perspectives
• Builds a shared understanding of what needs to be
done and what items may potentially affect completion
• Creates shared commitment to achieving the sprint
goals and will give everyone – from analyst to developer
to tester – a vision for how complex the work will be
• Use modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20)
to size user stories
• Always triangulate with other stories, e.g. an 8 point
story should take 4 times longer than a 2 point story
• Avoid Outliers- ensure that stories have similar sizes,
e.g. stories having sizes 3,5,8 instead of sizes 1,5,13
• This increases predictability, reduces variability

26. 26
Sprint Backlog Estimation (Using “Planning Poker”)
Each estimator gets a
deck of cards
Product/Service
Owner reads a
story
Estimators
privately select
cards
Cards are turned
over
Discuss
Differences
Re-estimate
Each estimator is given a
deck of cards with the
values listed above.
For each backlog item to
be estimated,
Product/Service Owner
reads description.
Each estimator privately
selects a card
representing their
estimate.
All cards are
simultaneously turned
over so that everyone
can see each estimate.
High and low estimators
explain their differences..
Re-estimate until
estimates converge. Use
timer if process takes too
long.
Adapted from Mike Cohn. Agile Estimating and Planning, 2005.
Using “Planning Poker” in a Sprint Planning Session combines expert opinion, analogy, and
disaggregation for quick but reliable estimates

27. 27
Exercise #3: Planning Poker for User Stories (Template)
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
Participate in Planning Poker session to size user stories from story map. Use Sizing Board.
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
As A:
I want:
So That:

28. 28
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Teams Participated in Planning Poker session and used Sizing Board for sizes like these:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
Exercise #3: Planning Poker for Epic “Send Money Using Mobile Devices” (Example)
3 5 8

29. 29
Agenda
Agile and Scrum Flow – A Recap
Agile for Teams2
Sizing, Estimating and Prioritizing Backlogc
Definition of Ready, Definition of Doned
Agile Engineering Principlese
1
Lean Thinking with Ball Point Gamea
Scrum Team Member- New Expectationsb

30. 30
Definition of Done: Accepting User Stories
A User Story is accepted when it satisfies the Definition of Done (DoD) and is accepted by the
Product/Service Owner
Developers and testers
stick to DoD, predefined
criteria for backlog items
DoD
STORY
STORY
STORY
STORY
STORY
Agile Team Product/Service Owner
Product/Service Owner reviews
Acceptance Criteria w.r.t. finished
work and accepts/rejects/defers
story

31. 31
Definition of Done: What is it?
Removes ambiguity:
Eliminates the
question, “What do
you mean by done?”
Clear and concise list of requirements that a software increment must adhere to for the team to
call it complete.
Guides estimation:
Helps teams better
estimate what it takes
to get to “done”
Standardizes delivery:
All deliverables held
to the same standard
of doneness

32. 32
Definition of Done: Examples for Dev and Ops
Exercise #4: Create your definition of done
Examples (Ops) Examples (Dev)• Configuration and
deployment scripts
checked into repository
• Environment has been
virtualized
• Environment stack
available in service catalog
• Capacity impact has been
determined
• Necessary documentation
is complete
• Code checked in,
integrated and built
• Unit tests created and
checked in
• Code has been peer
reviewed
• Product/Service Owner
has seen and approved
functionality
• Any necessary
documentation is
complete

33. 33
Definition of Ready: What is it?
Balances Responsibility:
Product/service owner has
accountabilities to team
Criteria a backlog item must meet in order for the team to accept accountability or delivery
Encourages diligence:
Entire team has same goal
during backlog refinement
Helps sizing:
More consistent inputs
lead to more consistent
sizing

34. 34
Definition of Ready: Examples for Dev and Ops
Exercise #4: Create your definition of ready
Examples (Ops) Examples (Dev)• Capacity needs have
been identified and
estimated
• Impact to existing
capacity has been
determined
• SLAs have been
captured
• Monitoring needs have
been determined
• Story defined with
acceptance criteria
• Dependencies
identified
• Sized by TEAM OS
SMEs/Functional
experts identified
• UX artifacts created
• Any necessary
documentation is
complete

35. 35
Exercise #5
The team has created a robust and agreed upon definition of ready. The
Product/Service Owner demands the team commit to user stories that do not
meet the definition of ready.
The Product/Service Owner threatens to escalate to management and
stakeholders, by saying “I don’t have time to do this definition of ready stuff.
I never agreed with it anyway.”
What do you do in this situation?

36. 36
Agenda
Agile and Scrum Flow – A Recap
Agile for Teams2
Sizing, Estimating and Prioritizing Backlogc
Definition of Ready, Definition of Doned
Agile Engineering Principlese
1
Lean Thinking with Ball Point Gamea
Scrum Team Member- New Expectationsb

37. 37
Agile Engineering Principles
Frequent
releases
Technical
Excellence
to Welcome
Change
• True agility happens when changes are easy, fast, and flexible
• Organizational agility is constrained by technical agility (the last mile)
• Agile engineering practices help teams produce high quality work
• Agile engineering practices enable “Quality Built In”

38. 38
Agile Engineering Principles: Continuous Integration for scaling
Continuous Integration (CI) is a software development practice, where team
members integrate their work frequently, leading to multiple integrations per day
• Each integration is verified by an automated build (including test) to detect
integration errors as quickly as possible.
• With continuous integration developers gradually grow a stable system by
working in small batches and short cycles
• This enables teams to work on shared code and increases visibility into the
development and quality of the system

39. 39
Agile Engineering Principles: Continuous integration for scaling (Continued)
CI is a
Developer Practice
CI aims to keep a
working system
CI relies on
small changes
• On large products its hard because it requires a change to the daily habits of all
developers. This takes time and requires coaching.
• When a test fails, locally or on the CI system, the developer fixes it immediately and
therefore always keeps a working and stable system
• Large changes to a stable system will destabilize, sometimes break it in large ways
• The larger the change, the more time it takes to get the system back to a stable state
CI helps you
grow the system
• Growing a system implies nurturing it, since it evolves into a larger system

40. 40
Agile Engineering Principles: Continuous integration for scaling (Continued further)
Continuous Integration requires that you
integrate on the main line at least daily
Continuous Integration works best with
lots of automated unit tests
• Branching during development breaks the
purpose of ci and should be avoided, with 2
common exceptions.
• Customers may not want to upgrade
their product to the latest release but
still want patches.
• When scaling up a CI system, it can be
useful to have very short-lived branches
that quickly get integrated into mainline
• Its not very hard to have a CI system simply
compile source, but its not very useful either
• You want to have as many tests as possible
running in your CI system
• The more automated unit tests, the better
your safety net and the more confidence that
your system is working
• CI is stepping stone for Continuous Delivery
(CD)

41. 41
Agile Engineering Principles: Unit testing for DONE-DONE
Uses the same
programming
language
Usually runs
very quickly
• Unit tests are usually written in the same programming language as their code
under test and unit test cases are often grouped into Test Suites
• Each Unit test should be small and test only a limited piece of code functionality
• Usually, we expect to run hundreds of unit tests cases within a few seconds
Many Unit Test
Frameworks
• The most popular ones follow an xUnit pattern invented by Kent Beck
• e.g., JUnit for Java, NUnit for .net, cppUnit for C++, ABAPunit for SAP

42. 42
Agile Engineering Principles: Unit testing for DONE-DONE (Continued)
Facilitates changes
• It protects the
behaviors created by
previous developers
• Makes it easy to add
new functionality or
refactor existing
code
Simplifies integration
• Tests basic units of
code, ensuring these
basic units work as
expected
• When these units are
integrated, it becomes
easier to separate the
integration issues
from the internal unit
specific issues
Improves
communication
• Good unit test can
communicate
intended
functionality
• Unit test doesn’t
“lie”. If it fails, either
the test or the code is
wrong
Helps design
• Unit tests require
testability from code
perspective
• Testable code
requires better
modularity and
cleaner dependencies

43. 43
Agile Engineering Principles: Test Coverage Measurement for DONE-DONE
Helps teams understand areas
of risk in the code
Helps measure and track unit
test coverage over time
Helps point out areas of
“crustiness” in the code
Code coverage tools like Clover & JaCoCo enable direct measurement of test coverage
Helps triage the unit testing
effort

44. 44
Testing moves project
forward
Agile Engineering Principles: Summary
From “Test Last” to
“Testability up Front”
Tested is a
part of “Done”
Everybody
Tests
Traditional Team
• Testers are responsible for
all testing activities
Agile Team
• Testing done is the
responsibility of the whole
team
• Team only moves as fast as
the slowest part
• To eliminate the
bottleneck, everyone tests
Agile Team
• Agile teams don’t count
something as “done” until
it has met the acceptance
criteria, which includes
testing
Traditional Team
• With a strict division
between dev and test, it’s
typical for developers to
say they are “done” when
they have implemented it,
but before its tested.
Agile Team
• Tests are defined with the
user stories.
• Those tests are used to
drive the development
effort with more clarity and
shared focus
Traditional Team
• User stories and design
come first, then
development.
• The tests follow (near the
end of the project)
Traditional Team
• QA/test group serves as the
quality gatekeeper
• Responsibility of QA to
prevent bad software from
being released
Agile Team
• Team builds the product
well from the beginning
using testing (automated
and manual)
• Consistent feedback
provided on how well
product is meeting business
needs

45. 45
Agile Engineering Principles: Role of Operations in agile teams for DONE-DONE
How does Dev
and Ops turn
conflict into
collaboration?
Better
communication
Shared planning
Shared goals and
incentives
Shared processes
and tools
Shared solutions
• Development and Ops work
together in overall program, and
possibly during each iteration
development of features
• Decoupling deployment and
release processes creates faster
delivery
• Ops team members can attend
Scrum process ceremonies, as and
when they are invited
• Tools like git, Jenkins, and Maven
are used by both development and
ops team for both development
and operations tasks
• Development teams and ops teams meet and collaborate
multiple times per week
• Ops team is involved with planning
and nonfunctional user stories from
the inception of a program
• Ops is treated as both a stakeholder
and a customer in the development
process
• Only deploying qualified changes to
production
• Automating the process as much as possible
to prevent headaches on both sides

46. 46
Exercise #6
There is a severity 1 issue in a feature.
How can we figure out what’s going on?
How can we prevent this situation in future?

47. 47
Exercise #7
The team thinks it would be a good idea for QA to work with the
Product/Service Owners to flesh out acceptance criteria for upcoming user
stories.
The Product/Service Owners welcome the help, but QA is hesitant, by saying
“It’s not up to me to define what to test. I test per the spec and test plan
only.”
How do you handle this?

48. Thank You