Do Agile, Be Agile

Workshop

1
WHOLISTIC AGILE TRANSFORMATIONS

2
Copy Right Notice
© 2015 by Xebia
All rights reserved. No part of this document may be reproduced or distributed in any form or by any means, or stored in a data
base or retrieval system, without prior written permission of Xebia.

This materials has been developed by refereeing CSM outline

If any external material is used, the source has been acknowledged on the relevant slide

We acknowledge all copy rights and trademarks of various organization

3
Getting to know each other

Your Name
Organization
Your Current Role
Experience with Scrum
Expectation from the Workshop

4
Logistics

5
Workshop Approach

Questions
Exercises and Discussion Participatio
Lecture s n by all
answers

6
Rules of Engagement

Participate
One person speaks at any given time
Keep discussions and questions to the point
Turn off your cell phones and other communication
devices
Be prompt returning from breaks
Provide feedback as to where course can be improved
– it will be useful for sub-sequent sessions

7
Completion Criteria
Successful completion of this course requires that participants

Actively participate in
classroom discussions
and exercises both the
days

Do not miss any

classroom time

8
Reference Material Used
1. Agile Retrospectives: Make Good Teams Great – Esther Derby, Diana Larsen, Ken Schwaber
2. Agile Estimating and Planning – Mike Cohn
3. User Stories Applied: For Agile Software Development: Mike Cohn
4. Agile Project Management with Scrum: Ken Schwaber

9
Workshop Agenda
Scrum Overview / Lifecycle

Scrum Roles

Scrum Estimation and Planning

Scrum User Stories

Scrum Final Thoughts

11
Traditional View of Product Management

Identify customer needs

Establish targets specifications

High level requirements

Develop functional specs

Hand off to development

12
Traditional Approach
Requirements
Gathered

Architecture
Designed

Coding
Completed

Testing

Sequential – series of steps

Product Completed after months, if not years

13
The Shunt Effect

4 4 40 4
Weeks
Analysis Design Weeks
Code Weeks
Test
Weeks

CONSTRUCTION

4 5 42 1
Weeks
Analysis Weeks
Design Weeks
Code Week
Test

As each phase of the project is delayed, the remaining phases get moved back but the deadline
remains the same, causing compression in the last stages. Delays are often caused by individuals
who are reticent to sign-off the preceding stage.

14
Challenges in Software Development

Requirements change
Customers never knows exactly what they need
Requirements are incomplete
People rarely understand requirements from the beginning
People make mistakes but it’s hard to fix them on the latter stages of development
For most middle-to-large systems it is hard (impossible) to design everything in advance

15
When do requirements emerge?

New ideas When we see Our business is We must We do not What we build
for features working constantly respond to understand doesn’t always
emerge software, we changing, so our requirements work as well
also see our needs competition as we expect
improvements change

16
What customer really needs?

Design UML New technology

Plans?
documents? diagrams? implementations?

Customer needs working software that

improves their business!

17
Ensuring what gets built delivers value

18
Cost of Change Curve

Cost of change New cost of change

Requirements Analyze Code Test Integrate

Project stage Time

19
So …

It’s All About…

Change!

20
Therefore …

How are we adapting?

“
“ It is not the strongest of the species that
survives, nor the most intelligent that survives.
It is the one that is most adaptable to change.

- Charles Darwin

21
Introduction to Agile-Scrum

22
Agile Manifesto
INDIVIDUALS AND INTERACTIONS over PROCESSES AND TOOLS (emphasis on the
relationship of software developers than institutionalized processes and tools)

WORKING SOFTWARE over COMPREHENSIVE DOCUMENTATION (continuously provide

tested working software)

CUSTOMER COLLABORATION over CONTRACT NEGOTIATIONS (relationship is given high

preference than strict contracts. Negotiation process focuses on maintaining relationship)

RESPONDING TO CHANGE over FOLLOWING A PLAN (team authorized to adjust customer

needs during iterations)
THINGS ON THE RIGHT ARE IMPORTANT.
THINGS ON THE LEFT ARE MORE IMPORTANT!!

© 2001, this declaration may be freely copied in any form, but only in its entirety through this notice (source … www.agilemainfesto.org)

23
Agile Principles
The 12 Principles of Agile
1 2 3 4
Welcome changing
Our Highest priority is to satisfy Delivery working software
requirements , even late in Business People and Developers
the customer through early frequently from a couple of
development. Agile processes must work together daily through
and continuous delivery of weeks to months with a
harness change for customer’s out the project
valuable software preference to a short timescale
competitive advantage

5 6 7 8
Build projects around motivated The most efficient and effective Agile processes promote
individuals. Give them the method of conveying sustainable development. The
Working software is the primary
environment and support that information to and within a sponsors, developers and the
measure of progress
they need and trust them to get development team is a face to users should be able to maintain
the job done face conversation a constant pace indefinitely
9 10 11 12

The best architectures, At regular intervals, the team

Continuous attention to Simplicity-the art of maximizing
requirements, and designs reflects on how to become more
technical excellence and good the amount of work not done is
emerge from self organizing effective, then tunes and adjusts
design enhances agility essential
teams its behavior accordingly

© 2001, this declaration may be freely copied in any form, but only in its entirety through this notice (source …
www.agilemainfesto.org)

24
Plan driven versus Value driven

Variable Cost Date Scope

Plan
Driven
Value
Driven

Fixed Scope Cost Date

Source: Agile Consortium / DSDM

25
 Agile …

is a culture
is a mindset
creates transparency
does NOT solve all your problems

Source: https://www.box.com/shared/mg9kq3d17e

27
What Makes Agile Work?

Better collaboration with business

More adapted to change/learning
Communication
Motivation
Shared ownership
Time box
Inspect & Adapt
Focus on the real thing
Collocation
Information radiators
Short feedback loops
Team autonomy
Accepted Responsibility

28
When is Agile best?

Creative Projects
New Technology Introductions
New Process Designs
Projects driven by critical business timing.
Project with poorly defined needs

29
Learning Agile – Scrum Basics – At a High Level

30
 New Product Development is empirical

Requirements change
Environment and prerequisites are incomplete
Knowledge about the solution is incomplete

Therefore:
­ Learn from doing
­ Decide as late as possible
­ Get feedback early and often
­ Adapt to change
Source: https://www.box.com/shared/mg9kq3d17e

31
Scrum is…
an Agile product development framework with a simple set of rules

not a process

not specific for IT

often supplemented by technical practices and insights from other fields, such as
Social Sciences.
The Scrum Framework
3 Roles
­ Product Owner
­ Scrum Master
­ Development Team

3 Artifacts
­ Product backlog
­ Sprint backlog
­ Product increment

5 Activities/Meetings
­ Product backlog refinement
­ Sprint planning
­ Daily Scrum
­ Sprint review
­ Sprint retrospective

Definition of Done
Transparency providers
SCRUM – At a Glance
Input from End-Users,
Customers, Team and
Other Stakeholders
ScrumMaster
Daily Scrum
Product Meeting & Artifacts Update
Backlog
Development Refinement
Team Sprint
1-4 Weeks
Product Owner Review

Team Selects
Potentially Shippable
How Much To
Product

S
SK
Commit To Do
Increment

TA
By Sprint’s End
Product
Backlog Sprint Planning Sprint No Changes
Retrospective
Meeting Backlog in Duration or Goal

34
Scrum

Scrum is an empirical process based on:

­ Transparency
­ Inspection
­ Adaptation

Scrum values are:

­ Focus
­ Courage
­ Openness
­ Commitment
­ Respect

INSPIRE CHANGE ACT ON RESULTS

SCRUM is Timeboxed

36
Scrum Roles

Scrum Master

Development
Product Owner Team

SCRUM
Roles

Details explained for each role in next few slides

37
Scrum Master

1 person
Removes the Team’s
The Scrum constraints and
Master’s job is to impediments (“blocks”)
prioritize these
problems and help Protects the Team
This puts stress
the organization from disruption or
on the team
overcome them disturbance
and
organizations, Coaches everyone to
exposing be successful with
Most projects deliver
underlying Scrum
software every 6 to 18
months. Scrum reduces problems and
this to limitations
2-4 weeks

38
Scrum Master Responsibilities
Removing the barriers
Responsible,
between the team and
the customer It Leader vs. Facilitator Humble,
Improving productivity of concept, Ideally Collaborative,
Teaching the customer
the development team in
how to maximize ROI 1 person per Scrum Committed,
any way possible
and meet their Team Influential,
objectives.
Knowledgeable

Ideally 100% dedicated Avoid having a manager

to this role – but in some as SM
cases it could be a team-
member playing the role – Team won’t self-
and also doing organize or take true
development, testing ownership

39
Product Owner Responsibilities

1 person
Owns vision for what should be produced
Manage the return on investment (ROI)
­ Establishes baseline target ROI
­ Measures project against this baseline
­ Prioritizes product backlog to maximize ROI
Call for releases
­ Decides when to call for an official release of a potentially shippable product increment
­ Can shift a release forward or backward to maximize ROI based on new knowledge

40
Product Owner Responsibilities

Guides product development

­ Establishes, communicates and nurture the vision
­ Knows what to build and in what sequence
­ Tunes the vision with the team
­ Creates and maintains the Product Backlog
­ Final decision maker about order of Product Backlog
items

Should be …
­ Knowledgeable – clear on goals and how to deliver
success
­ Empowered to make decisions – not just a “go-
between”
­ Immediately available to the Team, for questions and
clarifications

41
Development Team
Every one necessary to go from product backlog to potentially
shippable product increment, including
­ Programmers, Testers Analysts, DBA’s, Tech Writers, UI
Designers
­ Others as required

7 people, +/- 2

Cross-functional (must include design, coding, testing, and any

other skills required for potentially shippable software at end
of Sprint)

Self-organizing and self-managing

42
Development Team Attributes
Self organizing
Cross functional with no roles
Seven plus or minus two
Responsible for committing to work
Authority to do whatever is needed to
meet commitment
Open, collocated space
Resolution of conflicts, Rules of
Etiquette
Motivated to deliver excellent software
Motivated to improve their skills and
abilities
Willing to help each other, and to work
outside their “comfort zone”

43
Team Space and Co-Location
A key element of Agile project is the need for real time dynamic communication
with in the team and across the team (with external stakeholders)
One way of accomplishing this is to use co-located teams and usage of low tech
communication tools that are easy to understand and easy for the team to keep the
information upto-date

Physical space and co-location

­ The most effective layout for the physical team location is co-located desks and shared
access to plans, status, next steps, and other project planning and management tools.
­ Team members are not separated from each other by offices or cubicles, but rather share
desk and team space in an open concept environment.

44
Roles and Responsibilities Exercise
Refer to Instructions as provided in the binder for this exercise

45
Definition of “Done”

46
Definition of Done (DoD)

Definition of Done is DoD is the primary reporting DoD would add

a simple list of mechanism for team verifiable/demonstrable
activities: members value to the product
Writing code, Focusing on value-added
Coding comments, steps allows the team to
focus on what must be
Unit testing, completed in order to build
Integration testing, software while eliminating
Release notes, wasteful activities that only
complicate sw efforts.”
Design documents,
etc.

47
Definition of “Done” for the project across Sprints

For this team,

Product
Definition
Backlog Items that
of “Done” plete
co m don’t
For functionality to C ode
meet all these
be “Done” at the rev iewed
C od e criteria
end of a sprint, it
ts w ritten at the end of the
must have s
Unit te uted
ec Sprint
completed the and ex … isn’t Done!
following steps io n t e sted
at
Integr nted
e
Docum

# of defects permitted?
No major defects

48
What is done?

What is done?

Purpose: Understand differing views of what “done” is

Coming into Scrum team for the first time what might
your views be of “done” if your role is: Architect,
Analyst, Designer, Tester

Each team member depending on the role they play in

the team would have different notions of the DoD, It is
important that the DoD is defined by all the team
members and then proposed to the Product Owner for
finalization

49
Definition of Done (DoD)

DoD is not static

­ The DoD changes over time. 
­ Organizational support and the team’s ability to remove
impediments may enable the inclusion of additional activities into
the DoD for features or sprints.
­ Data from retrospectives are added to DoD as the team learns and
understands better

51
Exercise - Definition of Done (DoD)

Refer to Binder for Exercise on Definition of Done

Read the Case Study and Present your views as a Team

52
Ceremonies & Outputs in Scrum

53
SCRUM – A thought Process

Development Start

Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint

Initial Release Enhancement

Releases

54
Sprint Planning Meeting
Sprint Planning Meeting
­ Each sprint is preceded by a planning meeting, where the User Stories for the
sprint are identified and an estimated commitment for the sprint goal is made
Product Owner
Scrum Team
Customers
Management

Product Backlog
Existing Product Sprint Goal
Business Conditions Sprint Backlog
Technology Conditions
Sprint
Planning
Meeting

55
Sample Product Backlog
USER STORIES Size
As a BUYFROMME user, I want to see a page that shows detailed information about a books (such as price, high level abstract, user
reviews, etc.), along with thumbnail photos of the books 8

As a BUYFROMME user, I want to click the “buy” button to put the book in my shopping cart
5
As a BUYFROMME user, I want to click the shopping cart icon and see what’s in my shopping cart
5
As a BUYFROMME user, I want to remove an item from my shopping cart or change the quantities
3
As a BUYFROMME user, I want to click on a thumbnail photo to see a full-sized photo of a book
3
As a BUYFROMME user, I want to select a price range, and see all the books that are within that price range
3
As a BUYFROMME user, I want to select a type of book (paperback, E-book, Hardback etc.) from a drop-down list, hit submit and
then see a list of all the books that are of that type 5

As a BUYFROMME user, I want to enter a piece of text and click “Search books” and then see a list of all books that match any part
of that text (product search) 13

56
Sprint Planning – Inputs and Process
Product Owner must prepare the product backlog prior to
the meeting.
­ It is also his responsibility to prioritizes the Product
Backlog based on the understanding as derived from
meeting stakeholders and customers
The goal of the first segment, is for the team to select those
product backlog items that it believes it can commit to
turning into an increment of potentially shippable product
functionality.
The team can make suggestions, but the decision to what
product backlog can constitute the sprint is the
responsibility of the product owner.
The team is responsible for determining how much of the
product backlog that the product owner wants worked on
the team will attempt to do during the sprint.

57
Sprint Planning – Some more critical information
Customers, stakeholders, product owners, sales
& marketing, scrum team attends (minimum
required – Product Owner, Development team,
Scrum Master)
Team makes a commitment to do their best to
finish the Product Backlog items they’ve selected
Product Owner makes a commitment not to make
changes during the Sprint
Sprints are only planned one-at-a-time, and just-
in-time (at the beginning of each).
Scrum Team builds the Sprint Backlog

58
Sprint Goal to the Sprint Backlog
Development team takes the Sprint Goal and
decides what tasks are necessary to complete the
selected features.

Team self-organizes around how they’ll meet

the Sprint Goal.

Scrum Masters don’t make decisions for the

team.

Sprint Backlog (a list of tasks to be completed

during the Sprint is created).

59
Entering into a Sprint Backlog
Tasks are estimated in hours, usually 1-16

Team members sign up for tasks, they aren’t assigned (be patient, just wait!)

Estimated work remaining is updated daily

Any team member can add, delete or change the Sprint backlog (theirs or new)

If work is unclear, define a sprint backlog with a larger amount of time …break it down later.

Update work remaining as more is known, as items are worked

61
Sprint Backlog
Days Remaining 10 9 8 7 6 5 4
User Story # Task Details Committed By Status
Effort Remaining 325 298 251 230      

1 Draw a rough stekch of the concept Neha Completed   12 8 0 0      

1 Develop the UI Nandlal Completed   10 1 0 0      

1 Write the test case Peter Completed   9 0 0 0      

1 Execute UTP Sam Completed   5 2 0 0      

1 Perform Code Review Dan Completed   3 3 3 0      

2 Develop the UI Nandlal In Progress   14 12 7 5      

2 Write the test case Dan Completed   8 0 0 0      

2 Execute UTP Sam     6 6 6 6      

2 Perform Code Review Peter     3 3 0 0      

2 Setup database triggers Susan In Progress   10 12 9 1      

3 Develop the Report format Neha In Progress                

3 Define data for the report generation Susan Completed   3 0 0 0      

3 Write the test case Dan Completed                

3 Perform Code Review Peter                  

3 Execute UTP Sam                  

3 Integration with Menu Nandlal                  

62
Story Cards on Task Board

Source – http://www.goodagile.com – Pete Deemer

63
Daily Stand Up – During the Sprint

Goal:
Enable Team to inspect and adapt daily
Enable Team to share progress with each other
Surface what’s blocking or slowing down Team

15 minutes max for Team

No discussion or debate: listening only

Team and Scrum Master only

No Product Owner, Managers or others present.

Team can invite Product Owner if they wish, but it’s up to the team, Should the PO get
invited to the meet, PO does not contribute, but only listens

64
Daily Stand in Scrum – The How part

Same place and time every day

Three questions answered by each team member:
­ What I did yesterday?
­ What I plan to do today?
­ What impediments are preventing progress?
ScrumMaster listens for Risks and Issues / Impediments
Is NOT a problem solving session
Is NOT a way to collect information about WHO is behind the schedule
Is a meeting in which team members make commitments to each other and
to the ScrumMaster
Is a good way for a ScrumMaster to understand the progress of the Team

65
Daily Stand up in Scrum – Tips & Tricks of the Game
Feel of a stand-up
­ Quick, high energy
­ Motivated
­ Supportive
­ Self-organizing, facilitation not needed

Rules of the game

­ At start of the day to set focus
­ Close the circle, more of a huddle, standing!
­ Everyone has something to say: round robin fashion
­ Keep it short: no story telling or problem solving
­ Scrum Master takes the notes of blockers

66
When Sprints Ends …
At the end of a sprint, the Sprint Review Meeting is held. At this
meeting…
­ The software built by the team during the Sprint is demonstrated to attendees.
­ User interfaces, Test programs
­ User/Developer Documentation
­ Attendees can ask questions about the software and suggest changes to
requirements which are then added to the Product Backlog.
­ Customers can be surveyed to get feedback on team performance.

67
Sprint Review Meeting
Same people as planning

1 meeting plus any other

interested parties (e.g. end
users)
2 Team demonstrates that they
have completed the work as
planned in the Sprint Goal.

3 Customers / PO can provide

feedback, new ideas, changed
requirements, changed
4 Typically takes the form of a
demo of new features or
underlying architecture
priorities.

68
Managing Change in Scrum
Changes occur outside a Sprint when
­ Items on the product backlog are
­ Added
­ Removed
­ Reprioritized
­ Resources previously dedicated to a Sprint
need to be used for other priorities

Possibilities
­ Changes to the Product Backlog usually do not affect in-progress sprints.
­ When a change does affect a sprint.
­ The goal may need to be re-planned.
­ The sprint may need to be cancelled.

70
Sprint Retrospective

Process improvement at end of every Sprint

All team members reflect on the past sprint
Make continuous process improvements
Two main questions are asked in the sprint retrospective:
­ What went well during the sprint?
­ What could be improved in the next sprint?
Facilitated by ScrumMaster
What went well, what could be improved.
Scrum Master prioritizes based on team direction
Team devises solution to most vexing problems

71
If Retrospective are not done well … then …
None of us feel like we’re
Retrospective is a developing We have a high risk of
waste of time our skills losing team-members

Our quality is very poor. Open

We always forget
We never take action on bugs are piling up.
whatever we any of the issues we
agreed to do discuss
Team is under a lot of stress and
We never have time to make is starting to burn out Team motivation
improvements in our way of and morale
We don’t have any way of are very low
reminding ourselves working
We never finish what we committed to
in Sprint Planning

We’re always over-

committed in every Sprint Productivity is much
Everyone is micro-managing the team LOWER than it could be

The Product Owner

pressures us into over
The Product Owner gave committing The ScrumMaster
an unrealistic delivery date in Sprint Planning isn’t protecting us!
to the VP

73
Sprint Retrospective
The sprint retrospective is usually the last thing done in a sprint.

Many teams do it immediately after the sprint review

The entire team, including both the scrum master and the product owner should participate.

Typically schedule retrospectives for up to an hour, which is usually quite sufficient. However, occasionally a hot topic will arise
or a team conflict will escalate and the retrospective could take significantly longer.

Approaches to conducting retrospective

• There are many variations on this simple format.

• The scrum master can facilitate this meeting by asking everyone to just shout out ideas.
• The scrum master can go around the room asking each person to identify any one thing to start, stop or continue.
• Or, for example, the scrum master can tell everyone to focus on identifying something to stop this time because not
much attention has been paid to things to stop in recent retrospectives .

76
Abnormal Termination of Sprint

If a sprint is abnormally
Management can terminated, the next
Sprints can be
cancel sprint if external step is to conduct a new
cancelled before
circumstances sprint planning meeting,
the allotted time box
negate the value where the reason for
is completed
of the Sprint goal the termination is
reviewed

77
Product Backlog Grooming – During the Sprint

• Goal • Begin to think about • PO, Team & SM do this

• Look ahead to Product how they’ll be together each Sprint, at a
Backlog that’s coming implemented time of their choosing, and
soon for a duration of their
• Split large Product • Set a regular date choosing.
Backlog items into and time to do this
smaller ones every Sprint • Initially provide about 10%
• Start to get more of the time to this activity
detailed understanding and then Inspect and Adapt
of items

Product Product Product

Backlog Backlog Backlog
Grooming Grooming Grooming

78
Impact of Defects on Release Planning Exercise

Refer to the information as provided in the binder

79
What is a Information radiator?

"Two characteristics are key to a good information radiator. The first is that the information changes
over time. This makes it worth a person's while to look at the display... The other characteristic is that it
takes very little energy to view the display.“

80
Information Radiators – What can be displayed
The current
iteration’s work set
(Use cases or User
Stories)

The result of the

The current work
last reflection
assignments
workshop

The number of
The core of the
tests written (or
domain model
passed)

The status of key The number of use

servers (Up, Down, cases / stories
Under Maintenance) delivered

81
Make Information / results visible

82
Information Radiators

- Source – From Internet

83
Burn Down Charts

Are used to represent “work done”.

Are wonderful Information Radiators

3 Types:
­ Sprint Burn down Chart (progress of the Sprint)
­ Release Burn down Chart (progress of release)
­ Product Burn down chart (progress of the Product)

84
Sprint Burn Down Charts

85
Estimation & Planning in Agile –Scrum

88
Why Planning fails?
Planning is by activity rather than feature
Activities Don’t Finish Early
­ Parkinson’s Law (1957), which states that:
­ Work expands so as to fill the time available for its completion
Lateness Is passed down the schedule
Activities are not independent
Multitasking causes further delays
Features are not developed by priority
We ignore uncertainty
Estimates become commitments

89
What makes planning Agile?

Is focused more on the planning than the plan

Encourages change
Results in plans that are easily changed
Is spread throughout the project

90
Agile Scrum Project Lifecycle
PLANNING
VISION, RELEASE OR RELEASE OR RELEASE OR PROJECT
PRODUCT QUARTER QUARTER QUARTER RETROPECTIVE
ROADMAP

RELEASE
RELEASE
ITERATION ITERATION ITERATION RETROSPECTIV
PLANNING
E

DAILY STAND UP TASK TASK TASK UPDATE

MEETINGS COMPLETION COMPLETION COMPLETION PROGRESS

ITERATION
ITERATION DEMO, REVIEW,
DAILY WORK DAILY WORK DAILY WORK
PLANNING RETROSPECTIV
E

91
Measures of Size
Traditional and Agile Scrum measure size differently

Traditional Agile Scrum

Measures of size Measures of size
____________

Lines of code
Function Points
Story
points
Ideal days

92
Estimation - Exercise

Concept of the exercise is to show the relativeness in sizing of solutions / user stories

Follow the exercise instructions as provided in the binder

93
Sizing in Scrum
Sizing in Scrum is performed using story points

Story points are a unit of measure for expressing the overall size of a user story feature

The number of story points associated with a story represents the overall size of the story

There is no set formula for defining a size of the story

Story point is an amalgamation of effort involved in developing the feature, the complexity of developing it, the risk inherent in it and
so on

Sizing using story points is a relative concept, It is unit less in nature

A user story estimated as 10 story points is twice as big or risky as a story estimated as 5 story points

What matters are the relative values assigned to a different stories

94
Story Points

The “bigness” of a task

Influenced by
• How hard it is
• How much of it there is

Relative values are what is important

• A login screen is a 2.
• A search feature is a 8.

Points are unit-less

95
Story Point Scale
Value Meaning

0 No effort required

1 No. problem, We could do this in few hours

5 Most common use

Based on Fibonacci sequence, 8

a recurring organizational 13
pattern
20

40
The story point scale has no
statistically reliable relationship 100 Impossible, this is very large
to man hours
?… Need more information

96
Estimates are shared
Estimates are not created by a single individual on the team
Agile team do not rely on a single expert to estimate
Estimates are best derived collaboratively by the team, which includes those who
will do the work. There are 2 reasons for this:
­ First on an agile project, one would not tend to know who specifically would be working on a
given task
­ Secondly even though one may not be doing the work (like for examples specialized testing),
others may have something to say about the estimate
Additional accuracy in estimation efforts yields very
little value beyond a certain point

97
Deriving an Estimate
The 3 most common techniques for estimating are:

Expert Opinion
­ Ask an expert of the subject, as to how long will it take to do a work.
­ The expert relies on their intuition or gut feel and provide an estimate

Analogy
­ When estimating by analogy, the estimator compares the story being estimated with one or more other stories.
In this technique one compares the new story to the assortment of stories already completed or estimated

Disaggregation
­ Refers to splitting a story or a feature into smaller, easier to estimate pieces.
­ It would be very difficult to estimate a single story of 100 days.
­ The solutions to this is to break the large story or feature into multiple smaller items and then estimate those

98
Planning Poker

99
Planning Poker
The recommended method of estimation in agile is by playing planning poker
Planning Poker combines expert opinion, analogy and disaggregation, which results
in reliable estimates
Participants in planning poker include of all the agile-scrum team
For each user story, the moderator (usually the Product Owner) would read the user
story. The PO would answer any questions that the estimators would have
After all questions are answered, each estimator selects a card present their
estimates. Cards are not shown until all estimators have made their selections. At the
same time all cards are turned-over
Everyone shows their cards at the same time (Scrum Master says “1-2-3-Show”)
Should the estimates differ significantly, the high’s and the low’s
are requested to explain their rationale

100
Planning Poker
It is important that this difference should become an attacking point in discussion, it is
more to understand the other view
Post discussion on the differences, the planning poker is played again to see if the
differences are reconciled
In many cases, the differences will already converge by 2nd round, but if not, then
continue the same process
It will rarely take more than 3 rounds to converge.
Should the differences be like 5, 8, 8, 8, 8, 8. One can ask the lower estimator if the
person is OK with the high estimates
Should the differences be like 5, 5, 5, 5, 5, 8. Go with the highest estimator
Pick a number that everyone can live with
It is important to understand that point is not absolute precision but
more on reasonableness

101
Story Points Estimation with Planning Poker

Simultaneously,
each person
Each person
Team discusses shows estimate
chooses their
User Story estimate

Until the
numbers are
close People with high & low estimates
explain their reasoning

102
Sprint Planning – Best Practices

Divide the planning into 2

Defer Task
halves
Assignment

• In the 1st half, the PO • Many teams spend too Defer Unknown
briefs the team on the much time and effort Details
next priorities from the pre-assigning sprint
product backlog and the backlog items to team
team selects a set of members • Consider deferring the
items they deem task definition for those
reasonable things that are not fully
• Consider leaving the understood and simply
task assignment until
• In the 2nd half, the team later. This will allow
decomposition the team members the
commitments into the opportunity to self-
sprint backlog of action assign the tasks, thus
items and tasks needed generating more buy-
to accomplish those in
commitments

103
Three Levels of Planning / Release Plan

Sprint Plan/Release

Sprint
Planning

Release
Planning

104
 Iteration 1 Iteration 2
As a BUYFROM ME 3 As a Shipping Manager , I 5
user, I want to… want to…

As a BUY FROM ME 5 As a BUY FROM ME user, 2

user, I want to… I want to…

Code the UI 8
Write test fixture 6
Code middle tier 12
Write tests 5

“Yesterday I started on the UI;

should finish before the
end of today.”

105
 Iteration 1 Iteration 2
As a BUYFROM ME 3 As a Shipping Manager , I 5
user, I want to… want to…

As a BUY FROM ME 5 As a BUY FROM ME user, 2

user, I want to… I want to…

Code the UI 8
Write test fixture 6
Code middle tier 12
Write tests 5
Creating
this is
Sprint
“Yesterday I started on the UI;
planning should finish before the
end of today.”

106
Velocity and Size
To understand how unit less story points would
work, we need to introduce a new concept –
VELOCITY

Velocity is a measure of a team’s rate of progress. It

calculated summing up the number of story points
completed during a sprint

Therefore if a team completes 5 user story of 3

points each, then we would say that the team
velocity is 15

Now if a team completes 4 user story of 5 points

each, then we would say that the team velocity is 20

107
Velocity as Productivity concept

Duration 450/15 = 30 sprints

Calculation Velocity = 15

450 story
Size
points

108
Use Historical Data - Where Possible
Other concept is to use
Yesterday’s Weather (which
Sorted means take reference of the last
Velocities couple of iterations and plan for
27 your next one)
34
35
38
39
Use Median
40
40
41 90% confidence interval, Use
45 39 as your velocity in the team
and plan your future iterations
based on this

109
 Release Planning
– Lets run an example

110
Velocity of Team A

Sprint 1 Sprint 2 Sprint 3

24 Points 22 Points 25 Points

of size of size of size

Average of ~ 24 Points per Sprint is the “Velocity”

111
Stabilization Sprints
Sprint 1 Sprint 2 Sprint 3 Sprint 4

Stabilization
Sprint 1 Sprint 2 Sprint 3
Sprint

During “regular” sprints target friendly first use

­ Beta customers and similar can use immediately after sprint

During “stabilization sprints”

­ Team prepares a product for release
­ Useful during
­ active beta periods
­ when transitioning a team to Scrum
­ if quality isn’t quite where it should be on an initial release

Not a part of standard Scrum, but could be useful

112
Product Backlog as made available from the PO

113
Assume that now we should only be planning for “Must” + “Should” = 144

144 / 24 = 6 Sprints

Estimation Buffer+15%
Rework Buffer +10%
+10%
Additions Buffer

= 8.3 Sprints
Pre-release Sprint +1

= 9.3 Sprints
= 10 Sprints

114
Release Burndown Chart

Dev End Release

115
Release Burndown Chart

116
Release Burndown Chart

Dev End Release

117
Release Burndown Chart

118
Release Burndown Chart

Dev End Release

119
Release Burndown Chart

120
To release
on time,
remove 35
points of
Backlog
Dev End Release

To release full scope, 3

extra Sprints required

121
Release Planning Exercise
Refer to Instructions as provided in the binder for this exercise

122
Scaling Scrum for Distributed and
Multi-Location

123
Team Formation

9 People
(For example:
Analyst
Designer
3 Coders
3 Testers
Technical Writer)

124
Team Formation

50 People
(Analysts, Designers, Coders, Testers, Technical Writers, etc.)

125
Scaling SCRUM

Team A Team B Team C Team D Team E

Cross-Functional Cross-Functional Cross-Functional Cross-Functional Cross-Functional

(Designers, Coders, (Designers, Coders, (Designers, Coders, (Designers, Coders, (Designers, Coders,
Testers, etc.) Testers, etc.) Testers, etc.) Testers, etc.) Testers, etc.)

Idea from – http://www.goodagile.com – Currently Modified 126

Scaling SCRUM

Senior / Chief Product Owner

PO PO PO

Team A Team B Team C Team D Team E

Idea from – http://www.goodagile.com – Currently Modified 127

During the Sprint

Scrum of Scrums
Daily / 2-3 times per week
Coordination, Dependencies Mgt, Block Surfacing
Team A Team B Team C Team D Team E

Source – http://www.goodagile.com – Pete Deemer 128

Scrum of Scrum
Each day normally after the Daily Scrum.

• These meetings allow clusters of teams to discuss their work, focusing

especially on areas of overlap and integration.
• A designated person from each team attends.

The agenda will be the same as the Daily Scrum, plus the following four
questions:

• What has your team done since we last met?

• What will your team do before we meet again?
• Is anything slowing your team down or getting in their way?
• Are you about to put something in another team’s way?

129
Synchronizing Sprints
Backlog Item #1
• Identify the dependency before

Team B
Team A
Sprint Commitment is made

Then, either…
• Product Owner A reduces
priority of #1
or
• Product Owner B increases
priority of #14
or
• Product Owner A shifts #14
to Team A Product Backlog
and Team A builds it
Backlog Item #14
or
• Team A uses mock object in
place of #14, and replaces with
actual # 14 later

Product Backlog Product Backlog

131
Distributed Scrum Practices
Structure A: Product Owner is in Europe, team is in Pune, India
One Common Approach
­ Scrum Master is located with team in Pune, India
­ 2-week Sprints (this is the best and the ideal)
­ Team holds Daily Scrum in their own location, at a convenient time
(Product Owner does not join)
­ Scrum Master emails blocks list to Product Owner for assistance clearing in Europe
Product Owner travels to Pune, India for project kickoff
All real-time meetings between team and
Product Owner must be visual – audio is not
enough
­ Videoconference + Webex

132
Distributed Scrum Practices
Extensive use of Wikis and Google Docs for data sharing
­ Product Backlog and all related requirements and background information
­ Current list of blocks / impediments
­ Personal contact information and OK hours for contact for Product Owner,
Scrum Master and Team
At least 1 weekly 1-hour real-time check-in between Product Owner and team
In-person planning and review regroup in India between Product Owner and team
every 3-4 months

133
Distributed Team
Structure B: Team split between two locations
­ For example, 4 developers and 1 tester in India, 4 developers and 1 tester in US
Try to make it 2 teams
­ Even if we call them “1 Team”, they will always really be 2 teams
If 1 team:
­ Still need 2 Scrum Masters, one in each location
­ Lighter load than a full Scrum Master – may be a team-member
Daily Scrum
­ If time zones permit: 1 joint Daily Scrum Meeting via phone / webcam
­ If time zones are too different: 2 separate Daily Scrum Meetings, with notes from each team’s
meeting emailed to the other daily
Scrum Artifacts (Sprint Backlog, Burn down Chart) done electronically, in a shared
location – Use standard tools across both the team

134
Distributed Teams
Communication Tools
Distributed Teams

• Wikis, Webcams, Camera’s Online

• Technical, a team that does not sit directly with Chats and others
each other (could be different cities, different
locations, different floors in the same building) • Instant Messaging tools

• Usually refers to the development team that • At regular intervals get the team
works on the same project, but are located together
across multiple geographic locations or work
sites

• E.g. A team in India and North America working

on the same project, the developers would be in
India and the testing team could be located in
North America

135
Dispersed Team Recommendations

Co-locate team as often as possible,

Rotate members around.
especially at inception and key milestones.

Invest in (and plan for) tools that provide a

Plan to experiment.
shared environment.

Establish a single global instance of project Try virtual team building (team wiki &
assets, easily accessible by all. photos).

Establish known hours, with as much Apply high cohesion and low coupling to
overlap as possible. allocation of work to sites.

Apply Scrum-of-Scrums concept when

Develop a shared team vocabulary. mass remote meetings are
unproductive.

136
Requirements & User Stories

138
Written Requirements
How Much?
­ Scrum doesn’t specify
­ We can write as much or as little as we choose.
­ It’s up to the Product Owner and Team to decide together

Is it useful to create highly detailed written specifications for every single

Product Backlog Item in advance?
­ The time required to write is high
­ The time required to read is high
­ If a requirement is dropped, time will have been wasted
­ The risk of misunderstanding is high

139
Writing Specifications Effectively

User Stories are

short, plain-language
User stories as a descriptions of The 3 C’s: Card,
very widely used features, centered on Confirmation,
format the customer and Conversation
what
they need to do

140
Story cards

Story Cards
Story Cards

141
Story Cards

As a • “As a customer, I want to pay for

the items in my shopping cart
I want using a credit card, so that I can
to… have them shipped to me”

So that…

142
The Confirmation – Back of Card

“As a customer, I want to pay for the items in

my shopping cart using a credit card, so
Acceptance Criteria that I can have them shipped to me”
____________
_______________ “ The back of the card outlines the test cases
for this feature – how it’s going to be
confirmed.
• Accepts Visa, MC, AmEx and rejects
other types of card
Notes
____________ • Rejects invalid card number or expired
_______________ card
• Accepts different dollar amounts
• Rejects amount higher than the card
limit

143
The Conversation

The card only covers the most basic information

The next level of detail comes in conversations between the Product
Owner and the Team
When the team starts to understand the user story, the following
questions will make understanding of the element much easier:
­ Who the user is
­ What the user needs to do
­ Why the user needs to do that

144
Example – Online Shopping Portal

As a user,
I can read the reviews
of the books that I
want to purchase

As a shipping
As a user, I can return
manager , I can list of
the goods purchased
pending orders

As a user, I can
restrict searches so
that I only see photos
of the goods for
purchase

145
Details added in smaller sub stories
As a user , I register a
request to return the goods
purchased

As a premium site member,

I can return the goods
purchased with no penalty
As a user, I can return (with in 7 days)
the goods purchased
As a non premium site
member, I can return the
goods purchased with 10%
penalty

As a site visitor, I am
emailed a confirmation of
any cancelled request

146
Details added as tests
High Level tests are added to the story
­ Can be used to express additional details and expectations

As a user, I can return the goods purchased:

­ Verify that a premium member can return the goods without a penalty if the goods are return in 7
days of purchase
­ Verify that a non-premium member is charged 10% for return of purchased goods
­ Verify that an email confirmation is sent
­ Verify that the credit card is notified of any cancellation
­ Figure out what to do if the user’s card is expired

147
How to Evaluate a good Story INVEST

I- Independent
N- Negotiable.
V- Valuable
E- Estimate-able
S- Small
T- Testable

150
What is Independent?
One user story should be independent of another (as much as possible).

Dependencies between stories make planning, prioritization, and estimation much

more difficult.

Often enough, dependencies can be reduced by either combining stories into one or by
splitting the stories differently.

151
What does Negotiable mean?

A user story is negotiable.

The "Card" of the story is just a short description of the story which do not include
details.
The details are worked out during the "Conversation" phase.
A "Card" with too much detail on it actually limits conversation with the customer.

152
Valuable to Whom?
Each story has to be of value to the customer (either the user or the purchaser).

One very good way of making stories valuable is to get the customer to write them.

Once a customer realizes that a user story is not a contract and is negotiable, they will
be much more comfortable writing stories.

153
Can I Estimate is more accurately?

The developers need to be able to estimate (at a ballpark even) a user story to allow
prioritization and planning of the story.

Problems that can keep developers from estimating a story are: lack of domain
knowledge (in which case there is a need for more Negotiation/Conversation); or if
the story is too big (in which case the story needs to be broken down into smaller
stories).

154
How Small is small ?
A good story should be small in effort, typically representing no more, than 2-3 person
weeks of effort.

A story which is more than that in effort can have more errors associated with scoping
and estimation.

155
Can it be Tested?

A story needs to be testable for the "Confirmation" to take place.

We do not develop what we cannot test.
If you can't test it then you will never know when you are done.
An example of non-testable story: "software should be easy to use

156
Splitting of User Stories
At times it may become necessary for us to split the user stories into smaller stories:

­ When it is difficult to fit a user story in a single iteration

­ When there is not adequate time to fit the story in the current iteration, though it may be small
­ When there are operational requirements (like performance or any other non functional
specification)
­ Split stories based on CRUD operations
­ When the story is too big even to estimate

Do not try and split stories into tasks / activities

157
Splitting User Stories

Workflow Steps Data Methods

Business Rule Variations Defer System Qualities

Major Effort Operations

Simple/Complex Use Case Scenarios

Variations in Data Break Out a Spike

158
Split by Workflow Steps
Identify specific steps that a user takes to accomplish a workflow,
then implement the workflow in increments.

...I can publish pricing programs

to the customer’s In-Home
As a utility, I want to
update and publish Display
pricing programs to ...I can send a message to the
my customer... customer’s web portal

...I can publish the pricing table

to a customer’s smart thermostat

159
Split by Business Rule Variations

Business rule variations often provide a straightforward splitting scheme

...sort by zip code

As a utility, I can sort
customers by different ...sort by home demographics
demographics...
..sort by energy consumption

160
Split by Use Case Scenarios
If use cases are used to represent complex interaction,
the story can be split via the individual scenarios

• Use Case/Story #1 (happy path):

Notify utility that consumer has
equipment
As a user, I can enroll
in the energy savings • Use Case/Story #2: Utility
program through a retail provisions equipment and data,
distributor ... notifies consumer

• Use Case/Story #3 (alternate

scenario): Handle data validation
errors

161
Split by Operations / CURD Concept

Split by type of operation example: Create Read Update Delete (CRUD)…

• ...I can sign up for an account.

As a user, I can enroll
in the energy savings • ...I can edit my account settings.
program through a retail
distributor ... • ...I can cancel my account.

• …I can add more devices to my

account

162
Split – If All Else Fails, Break out a Spike

In some cases, a story may be hard to

estimate may be too large or overly complex

or perhaps the implementation is poorly

understood Technical Functional
Spike Spike

In that case, build a technical or functional

spike to figure it out;
then split the stories based on that result.

163