Scrum

Fascinating
World of Agile
By Amit Kulkarni

Scrum Master

Product Owner

Backlog

User Story

Team

DSDM

Sprint

Effective Project Management Consultancy

Effective PMC Private Limited

www.effectivePMC.com
[email protected]

Effective Scrum and Agile Coaching

Preface ............................................................................................................................................ 8
SECTION I : INTRODUCTION .......................................................................................................... 10
1

Introduction to Agile.............................................................................................................. 12
1.1

Agile Software Development ......................................................................................... 12

1.2

DSDM Approach to definition of Agile ........................................................................... 14

1.3

FIVE Phases of a Agile Project ........................................................................................ 15

Agile Manifesto...................................................................................................................... 18
2.1

Agile values..................................................................................................................... 18

2.2

Agile Principles ............................................................................................................... 20

Exercise...................................................................................................................................... 24
Answers ..................................................................................................................................... 24
3

Agile Development Methodologies....................................................................................... 26

3.1

Adaptive Software Development ................................................................................... 26

3.2

Acceptance Test-Driven Development (ATDD) .............................................................. 26

3.3

Extreme Programming ................................................................................................... 27

3.4

DSDM.............................................................................................................................. 28

3.5

Test-Driven Development .............................................................................................. 33

3.6

Scrum.............................................................................................................................. 33

3.7

Lean Management ......................................................................................................... 33

Exercise...................................................................................................................................... 39
Answers ..................................................................................................................................... 40
SECTION II : UNDERSTANDING AN AGILE LIFECYCLE USING SCRUM METHODOLOGY ................ 42
4

Introduction to Scrum ........................................................................................................... 44

4.1

Brief History of Scrum .................................................................................................... 44

4.2

A Scrum Project .............................................................................................................. 45

The Scrum Team .................................................................................................................... 50

5.1

The Product Owner ........................................................................................................ 51

SAMPLE SELECTED PAGES

5.2

The Scrum Master .......................................................................................................... 52

5.3

The Development Team ................................................................................................. 54

5.4

Specialist Roles ............................................................................................................... 56

The Scrum Artifacts ............................................................................................................... 58

6.1

Product Backlog.............................................................................................................. 58

6.2

Sprint Backlog................................................................................................................. 58

6.3

Increment ....................................................................................................................... 59

6.4

Done Criteria .................................................................................................................. 59

Scrum Events ......................................................................................................................... 60

7.1

Timebox.......................................................................................................................... 60

7.2

Sprint planning meeting ................................................................................................. 61

7.3

Daily Scrum meeting ...................................................................................................... 62

7.4

Sprint Review Meeting ................................................................................................... 63

7.5

Sprint Retrospective....................................................................................................... 63

7.6

Release Planning Meetings ............................................................................................ 64

7.7

Backlog refinement (grooming) ..................................................................................... 65

7.8

Scrum of Scrums............................................................................................................. 65

Exercise...................................................................................................................................... 66
Answers ..................................................................................................................................... 67
SECTION III AGILE DOMAINS ...................................................................................................... 68
8

Introduction to Agile Domains .............................................................................................. 70

DOMAIN I Value Driven Delivery ........................................................................................ 74

9.1

Introduction.................................................................................................................... 74

9.2

Requirements Prioritization ........................................................................................... 76

9.3

Value Stream Mapping (Lean Practice).......................................................................... 79

9.4

Minimally Marketable Feature....................................................................................... 80

Exercise...................................................................................................................................... 82
Answers ..................................................................................................................................... 83
10

DOMAIN II : Stakeholder Engagement............................................................................... 86

SAMPLE SELECTED PAGES

10.1 Introduction.................................................................................................................... 86
10.2 Identifying Stakeholder Needs ....................................................................................... 88
10.3 Stakeholder Involvement ............................................................................................. 103
10.4 Manage Stakeholder Expectations............................................................................... 114
Exercise.................................................................................................................................... 119
Answers ................................................................................................................................... 120
11

DOMAIN III Adaptive Planning ...................................................................................... 124

11.1 Introduction.................................................................................................................. 124

11.2 Adaptation.................................................................................................................... 124
11.3 Levels of Planning......................................................................................................... 125
11.4 Agile Modelling............................................................................................................. 127
11.5 Velocity Based Planning ............................................................................................... 130
11.6 Commitment Driven Planning...................................................................................... 131
11.7 Kanban Method (Lean Practice)................................................................................... 132
11.8 WIP Limit for Planning and Limiting Work in an Iteration ........................................... 133
11.9 Agile Estimation............................................................................................................ 134
Exercise.................................................................................................................................... 140
Answers ................................................................................................................................... 141
12

DOMAIN IV : Problem Detection and Resolution ............................................................ 145

12.1 Introduction.................................................................................................................. 145

12.2 Agile Metrics................................................................................................................. 145
12.3 Identifying Problems .................................................................................................... 150
12.4 Resolving Problems ...................................................................................................... 157
Exercise.................................................................................................................................... 163
Answers ................................................................................................................................... 164
13

DOMAIN V : Continuous Improvements.......................................................................... 168

13.1 Introduction.................................................................................................................. 168

13.2 Quality in Agile ............................................................................................................. 168
13.3 Retrospectives .............................................................................................................. 170
SAMPLE SELECTED PAGES

13.4 Knowledge Sharing....................................................................................................... 175

13.5 Useful XP Practices advocating Continuous Improvement.......................................... 176
13.6 Process Tailoring, Systems Thinking and Process Analysis .......................................... 179
Exercise.................................................................................................................................... 182
Answers ................................................................................................................................... 183
14

DOMAIN VI : Boosting Team Performance ...................................................................... 186

14.1 Introduction.................................................................................................................. 186

14.2 Team Formation ........................................................................................................... 186
14.3 Team Empowerment.................................................................................................... 188
14.4 Team Collaboration ...................................................................................................... 191
14.5 Team Commitment ...................................................................................................... 195
Exercise.................................................................................................................................... 197
Answers ................................................................................................................................... 198
SECTION IV Advanced Agile Concepts...................................................................................... 200
15

Risk Management in Agile ............................................................................................... 202

15.1 Risk Register ................................................................................................................. 202

15.2 Risk adjusted Product Backlog ..................................................................................... 203
15.3 Process of Risk Management ....................................................................................... 204
15.4 Risk Based Spikes.......................................................................................................... 210
16

Agile Contracting Methods .............................................................................................. 211

16.1 DSDM Contract............................................................................................................. 211

16.2 Money for Nothing and Change for Free ..................................................................... 211
16.3 Graduated Fixed Price .................................................................................................. 213
16.4 Fixed Price Work Packages........................................................................................... 213
17

Failure Modes and Alternatives ....................................................................................... 214

17.1 Top 12 Agile Failure Modes.......................................................................................... 214

18

Distributed Agile Teams ................................................................................................... 215

18.1 Handling Distributed Agile Teams................................................................................ 215

18.2 Managing Sprint Planning Meetings ............................................................................ 216
SAMPLE SELECTED PAGES

18.3 Handling Daily Stand up for Distributed Teams ........................................................... 218

18.4 Collaboration within a Sprint ....................................................................................... 219
18.5 Sprint Reviews .............................................................................................................. 221

SAMPLE SELECTED PAGES

SECTION I : INTRODUCTION

SAMPLE SELECTED PAGES

10

1 Introduction to Agile
When one thinks about project development methodologies, the first thing that comes to our
mind are the methodologies described in PMBOK guide or Prince2 Manual. Therefore a
question always arises in our minds, is another methodology really required?
The answer to this question lies in the fact that over the last 10-15 years the world of people
working in the Knowledge Environment has changed drastically. People working in the
Knowledge environments such as Information Technology (IT), Engineering, Teaching,
Scientists, Lawyers, Doctors often need to work differently than the conventional
Manufacturing environments. The key in the Knowledge environment lies in Communicating,
Collaborating, Adapting to provide maximum value, since everyone in the Knowledge world is
special they have something unique and they have something more to contribute than
following orders routinely. This is the thought process which has evolved the development
methodologies in the recent past in the Knowledge based environments.
Development methods exist on a continuum from adaptive to predictive. Agile methods lie on
the adaptive side of this continuum. One key of adaptive development methods is a "Rolling
Wave" approach to schedule planning, which identifies milestones but leaves flexibility in the
path to reach them, and also allows for the milestones themselves to change. Adaptive
methods focus on adapting quickly to changing realities. An adaptive team changes as per
needs of the project. An adaptive team will have difficulty describing exactly what will happen
in the future. The further away a date is, the more vague an adaptive method will be about
what will happen on that date. When asked about a release six months from now, an adaptive
team might be able to report only the mission statement for the release, or a statement of
expected value vs. cost.
Predictive methods, in contrast, focus on analysing and planning the future in detail and cater
for known risks. In the extremes, a predictive team can report exactly what features and tasks
are planned for the entire length of the development process. Predictive methods rely on
effective early phase analysis and if this goes very wrong, the project may have difficulty
changing direction. Predictive teams will often institute a Change Control Board to ensure that
only the most valuable changes are considered.

1.1 Agile Software Development

Agile software development is a group of software development methods where requirements
and solutions evolve through collaboration between self-organizing, cross-functional teams. It
promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative
approach, and encourages rapid and flexible response to change. It is a conceptual framework
that promotes foreseen tight interactions throughout the development cycle.
SAMPLE SELECTED PAGES

12

2.2 Agile Principles

In addition to the four Agile values, the authors of the Manifesto created twelve guiding
principles for agile methods. Following are the 12 principles
1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Working software is the principal measure of progress
5. Sustainable development, able to maintain a constant pace
6. Close, daily cooperation between business people and developers
7. Face-to-face conversation is the best form of communication (co-location)
8. Projects are built around motivated individuals, who should be trusted
9. Continuous attention to technical excellence and good design
10. Simplicitythe art of maximizing the amount of work doneis essential
11. Self-organizing teams
12. Regular adaptation to changing circumstances
1. Customer satisfaction by rapid delivery of useful software
o We should focus on Customer. Satisfying only our own management or PMO
should not be our only goal.
o We must structure the project and projects team to deliver early and then
deliver frequently
o We must deliver valuable software and not just WBS items, documentation and
plans/ The focus should be on end goal.
2. Welcome changing requirements, even late in development
o Changes can be great for a project if they allow us to deliver some late highpriority features.
o From a traditional project management perspective, the changes are often seen
negatively and finally only the high-priority changes go thru.
o Agile projects accept that fact that changes will happen. XP methodology infact
states clearly to Embrace Change. This principle states that instead of
suppressing changes, the teams should embrace change and keep the project
adaptive and flexible as long as possible.
3. Working software is delivered frequently (weeks rather than months)

SAMPLE SELECTED PAGES

20

Exercise
1. Which Agile Manifesto value is concerned with team empowerment?
A.
B.
C.
D.

Customer collaboration over contract negotiation

Individuals and Interactions over processes and tools
Working Software over comprehensive Documentation
Responding to Change over following a plan

2. Which of the following is not a value pair expressed in Agile Manifesto?

A.
B.
C.
D.

Individuals and Interactions over processes and tools

Working Software over comprehensive Documentation
Responding to Change over following a plan
Customer Collaboration over Meetings

3. What is the meaning of Simplicity?

A.
B.
C.
D.

Maximizing the amount of work done

Maximizing the amount of work not done
Minimizing the amount of work not done
Be straightforward in your communication

4. An organization PMO has 4 Agile projects but each one implements Agile principles
differently. How should PMO respond to this situation?
A.
B.
C.
D.

Accept that Agile is implemented differently on different projects

Prepare a Standard Operating Procedure and distribute to all projects to follow
He should conduct knowledge sharing sessions by the senior most Agile Coach
Organize Scrum of Scrums

Answers
1. (B) Individuals and Interactions over process and tools speaks about benefits of
empowerment and how they outweigh the benefits of processes and tools. The other
options do not talk about empowerment.
2. (D) Customer Collaboration over Contract Negotiation is the right pair.
3. (B) Simplicity is about Maximizing the amount of work not done
4. (A) Agile does not look exactly the same on all projects. That is what happens if you have
empowered teams. Therefore it is ok to have Agile being implemented differently on
different projects as long as they follow the basic principles of Agile.

SAMPLE SELECTED PAGES

24

3 Agile Development Methodologies

Following are some of the popular Agile Development Methodologies

Adaptive Software Development (ASD)

Acceptance Test Driven Development (ATDD)
Dynamic Systems Development Method (DSDM)
Extreme Programming (XP)
Lean software development
Test Driven Development (TDD)
Scrum

3.1 Adaptive Software Development

Adaptive Software Development (ASD) is a software development process that grew out of
rapid application development (RAD) work by Jim Highsmith and Sam Bayer. It embodies the
principle that continuous adaptation of the process to the work at hand is the normal state of
affairs.
Adaptive Software Development replaces the traditional waterfall cycle with a repeating series
of speculate, collaborate, and learn cycles. Thus, this method favors rapid and iterative
prototyping instead of detailed and comprehensive plans. This dynamic cycle provides for
continuous learning and adaptation to the emergent state of the project. The characteristics of
an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven,
and change tolerant.
The word, speculate refers to the paradox of planning it is more likely to assume that all
stakeholders are comparably wrong for certain aspects of the projects mission, while trying to
define it. Collaboration refers to the efforts for balancing the work based on predictable parts
of the environment (planning and guiding them) and adapting to the uncertain surrounding mix
of changes caused by various factors technology, requirements, stakeholders, software
vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations
with design, build and testing. During these iterations the knowledge is gathered by making
small mistakes based on false assumptions and correcting those mistakes, thus leading to
greater experience and eventually mastery in the problem domain.

3.2 Acceptance Test-Driven Development (ATDD)

Acceptance Test-Driven Development (ATDD) is a development methodology based on
communication between the business customers, the developers, and the testers. ATDD
encompasses many of the same practices as Specification by Example, Behavior Driven
Development (BDD), Example-Driven Development (EDD), and Story Test-Driven Development
SAMPLE SELECTED PAGES

26

SECTION II : UNDERSTANDING AN
AGILE LIFECYCLE USING SCRUM
METHODOLOGY

SAMPLE SELECTED PAGES

42

4 Introduction to Scrum
Scrum is an iterative and incremental Agile software development framework for managing
software projects and product or application development. Its focus is on "a flexible, holistic
product development strategy where a development team works as a unit to reach a common
goal" as opposed to a "traditional, sequential approach". Scrum enables the creation of selforganizing teams by encouraging co-location of all team members, and verbal communication
among all team members and disciplines in the project.
A key principle of Scrum is its recognition that during a project the customers can change their
minds about what they want and need (often called requirements churn), and that unpredicted
challenges cannot be easily addressed in a traditional predictive or planned manner. As such,
Scrum s founded on Empirical Process Control Theory, or empiricism. Empiricism asserts that
knowledge comes from experience and making decisions based on what is known. Scrum
Employs an iterative, incremental approach to optimize predictability and control Risk.

4.1 Brief History of Scrum

In rugby football, a scrum refers to the manner of
restarting the game after a minor infraction.
Scrum was first defined as "a flexible, holistic product
development strategy where a development team works
as a unit to reach a common goal" as opposed to a
"traditional, sequential approach" in 1986 by Hirotaka
Takeuchi and Ikujiro Nonaka in the "New Product
Development Game". Takeuchi and Nonaka later argued
in "The Knowledge Creating Company that it is a form of
"organizational knowledge creation, especially good at
bringing about innovation continuously, incrementally and
spirally".
The authors described a new approach to commercial product development that would
increase speed and flexibility, based on case studies from manufacturing firms in the
automotive, photocopier and printer industries. They called this the holistic or rugby approach,
as the whole process is performed by one cross-functional team across multiple overlapping
phases, where the team "tries to go the distance as a unit, passing the ball back and forth".
In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced
Development Methods, and Jeff Sutherland, with John Scumniotales and Jeff McKenna,
developed a similar approach at Easel Corporation, and were the first to refer to it using the
single word Scrum. In 1995, Sutherland and Schwaber jointly presented a paper describing the
Scrum methodology at the Business Object Design and Implementation Workshop held as part
of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in
SAMPLE SELECTED PAGES

44

5 The Scrum Team

Initially the Scrum guide had a Classification of a Chicken and Pig Role. The latest version of
Scrum Guide does not have these roles, however, let us understand the essence and Intent
behind the definition of the Chicken and Pig roles. Let us consider the following fable while
defining the 2 roles The Pig and the Chicken :
A Pig and a Chicken are
walking down the road.
The Chicken says: "Hey Pig, I
was thinking we should open
a restaurant!"
Pig replies: "Hm, maybe,
what would we call it?"
The Chicken responds: "How
about 'ham-n-eggs'?"
The Pig thinks for a moment
and says: "No thanks. I'd be
committed, but you'd only be
involved!"
The fable was referenced to define two types of project members - pigs, who are totally
committed to the project and accountable for its outcome, and chickens, who consult on the
project and are informed of its progress. This analogy is based upon the pig being able to
provide bacon (a sacrificial offering, for which the pig must die in order to provide) versus a
chicken which provides eggs (non-sacrificial).
The Primary Team roles (Pigs) in scrum are named as

Product Owner
Scrum Master
Development Team

SAMPLE SELECTED PAGES

50

8 Introduction to Agile Domains

The Agile Domains are complementary groupings of related areas of activity, concern or
function which adhere to the basic 12 principles of Agile as per Agile Manifesto
Agile Domains uniquely characterize and differentiate the activities found in one performance
domain from the others within the full scope of Agile project. Agile Managers / Scrum Masters /
Product owners actively carry out work within multiple Agile domains during the entire lifecycle
of the Agile projects.
The Agile domains in any Agile Lifecycle are shown in the figure below.

Value Driven
Delivery
Continuous
Improvement
(Product,
Process,
People)

Stakeholder
Engagement

Agile
Lifecycle
Problem
Detection
and
Resolution

Boosting
Team
Performance
Practices
Adaptive
Planning

We will study about each of the Agile Domains and the associated tools, techniques and best
practices in the following chapters.
Value Driven Delivery
Stakeholder Engagement
Adaptive Planning
Problem Detection and Resolution
Continuous Improvement (Product, Process, People)
Boosting Team Performance Practices

SAMPLE SELECTED PAGES

70

9.2 Requirements Prioritization

Prioritization is important while defining the requirements. Prioritizing is all about getting
attention focused on important things since budgets and time is always limited and also so that
the team is not confused and is not working on many things at a time.
Prioritization has to be based on customer value i.e. at any point in time, Do what is of most
value to the customer.
Providing Value to customer may include
New Revenue to the customer
Incremental revenue to the customer thru additional functionality or new products
Operational Efficiency thru cost savings
Catching up with Competitors etc
The following section describes various ways in which Prioritization is done by teams.

9.2.1 MoSCoW Prioritizing Scheme

There are numerous ways to prioritize, one of which is called MoSCoW which stands for

Must have The change is essential for the viability of the project
Should have The change is important and its absence weakens the Business Case
Could have The change is useful but its absence does not weaken the Business Case
Wont have (for now) The change is not essential nor important and can wait.

Must

Should

Could

Must

Could

Could

Timebox 1

Timebox 2

Timebox 3

9.2.2 Customer-Valued Prioritization

Customer-valued prioritization is concerned with working on the items that yield the highest
value to the customer as soon as possible. This technique aims to engage the customer in the
prioritization process, in which the team identifies high-value features and moves them up the
backlog of items to work on.
SAMPLE SELECTED PAGES

76

10.2.7User Stories
The User Story is the most granular unit of requirement on a Agile Project. The Product Owner
writes the User Stories.
It is important to note that the user story is a medium that helps in
Gathering basic information about requirements
Records high level requirements
Developing estimates
Defining acceptance test to validate successful completion
User Story is the starting point of Communication about the details of requirements and once
they are agreed then they represent the agreement between team and customer about what
customer can expect from implementation.
User Stories adhere to a specific, predefined structure and are a simplistic way of documenting
the requirements and desired end-user functionality. A user story tells you three things about
the requirements

Who,
What
Why

The requirements expressed in User Stories are short, simple and easy to understand
statements. The predefined, standard format results in enhanced communication among the
stakeholders are better estimations by the team. Some User Stories may be too large to handle
within a single Iteration. These large User Stories are often called Epics. Once Epics come up in
Prioritized Product Backlog to be completed in a upcoming Iteration they are further
decomposed in to smaller User Stories.
The Prioritized Product Backlog is a dynamic list that is continuously updated because of
reprioritization and new, updated, refined, and sometimes deleted User Stories. These updates
to the backlog are typically the result of changing business requirements.
The Three components of a User Story are
Cards

The Card is meant to indicate that the story

is typically written by hand on a index card
about 4 X 6 inches in dimension. The idea
behind writing the story on a card is to try
and limit the size of User Story.
When you write like this the author of the
story has to take efforts in making the story
less verbose and clearer to the team.

SAMPLE SELECTED PAGES

93

Conversation

Conversation means that the Story should

be the starting point of the conversation
between the team and the Product Owner
who typically would write the Story.
The Story should leave the implementation
details to the team who have a potential to
innovate and try to implement it.

Confirmation

Confirmation means that you typically have

to provide acceptance criteria for the story.
Acceptance tests are typically written on
back of the card and help the team
understand how the work done satisfies the
requirements.

Another Acronym to describe the Attributes of a User Story is INVEST

Independent

Story should be as far as possible independent of each other and

deliverable as a unit

Negotiable

Leave room for negotiation for nature of implementation

Valuable

That is it should result in some value to the Customer

Estimable

User Story should be clear enough for the team to come up with
reasonable estimates to work on

Small

Story should not be so big that it cannot be done within an iteration.

Agile requires that story should be no more than 40 man hours of effort

Testable

It should be possible to test the Story for correctness based on

description and success criteria provided.

10.2.7.1 User Story Format

As a <role/persona>,
I should be able to <requirement>
so that <benefit>
User Story Examples

SAMPLE SELECTED PAGES

94

User Story Example #2

User Story Example #1

Front and Back of Card Example#3

Acceptance Criteria details should be added and following information can be added to provide
context
GIVEN [Context] <and/or [Some more Context]
WHEN [Event]
THEN [Outcome]
<and/or [another Outcome]
Example: A Ticket booker needs to be prevented from making excessive bookings in a day. This is to
avoid Ticket Booking Agents from booking tickets on behalf of others and in turn charging a
premium from individuals.
GIVEN that the ticket booker places another ticket booking Request
WHEN The ticket booker has already booked 3 tickets today (Maximum tickets to allowed per day
= 3)
THEN Flash a message that you are not allowed to book for than 3 tickets a day

SAMPLE SELECTED PAGES

95

11 DOMAIN III Adaptive Planning

11.1Introduction
Planning in Agile is considered as a speculative activity. i.e. you make a forecast that is
reasonable based on available information. Planning in Agile is unlike the traditional methods
where plans are watertight and that the concepts such as Baseline are prevalent.
Agile Planning adheres to the principle in the Agile Manifesto which says We respond to
change as opposed to the fact that we follow a Plan
Some things to be kept in mind while planning in Agile

Planning is Speculative
You refine the plan as you go along
The Plan is elaborated and becomes more clear over a period of time
Planning is dependent on principle of Timeboxing. i.e. fix the time and resources
available and determine the features that can be delivered.
Plan has to be necessarily flexible and responsive to changes
Planning is an ongoing activity
Try not to pack too much into the plan. Allow space to accommodate changes
Iterations allow for mid-course corrections. The fact that we are developing in iterative
manner allows for mid-course correction while working on a release.
The release plan that you send out upfront is a initial guess at the plan. As the team
works on sprints, the team gets a reality check of the actual size and complexity of the
task it has undertaken.
The team also gains from feedback received from customers and stakeholders. Based on
this the team should stay on course towards the goal.
At the same time, the stakeholders should also work in adjusting to the reality. So in
reality, rather than fixing the goal, the stakeholder may want to define and keep
adjusting the zones of success.

11.2Adaptation

The fact that the planning is done iteratively allows the team to do mid course
correction if required.
The release plan that was sent out initially was just a initial guess.
As the team works on the iteration, the team gets a reality check about the actual size
and complexity of the tasks it has undertaken.
It may also gain from the feedback received from the customer and other stakeholders.
SAMPLE SELECTED PAGES

124

Based on this knowledge, the team should stay course of the goal.
At the same time the stakeholders should also adjust their goals in the face of the
reality. So in reality, rather than fixing their goal, the stakeholders may want to define
and keep adjusting the zones of success within which they expect the results to lie.

11.3 Levels of Planning

Plan at multiple levels (strategic, release, iteration daily etc) creating appropriate detail
using rolling wave planning and progressive elaboration to support the necessary level
of understanding.
Engage the team and customer in planning activities to create practical plans that
balance priorities and team capabilities in order to gain increased levels of commitment.
Planning in Agile happens at different levels represented by Planning Onion.

The planning could be at different levels

Daily (every day)

Iteration (Weekly)
Release (Month)
Product (2 years)
Portfolio (Long Term)
Strategic (Long Term)

The Team is involved at Daily, Iteration and Release Level. The daily planning happens thru the
daily standup meeting.
Iteration plans considers the tasks that are needed to transform a feature request into working,
tested software. Iteration plan happens at the beginning of every iteration.
SAMPLE SELECTED PAGES

125

11.8 WIP Limit for Planning and Limiting Work in an Iteration

A WIP (work in progress) limit is a strategy for preventing bottlenecks in software development.
This concept is based on the assumption that Multi-Tasking results in loss of time in context
switching.

Work in progress limits are agreed upon by the development team before a project begins and
are enforced by the team's facilitator. For example, a team may divide the tasks that must be
performed for a feature into design, code, test and deploy. When a WIP limit for a certain task
has been reached, the team stops and works together to clear the bottleneck. The goal of
working in this manner is meant to ensure that the entire team takes ownership of the project
and produces high quality code.
Consider the example below

The project is of 13 user stories to be implemented (A thru M) by a team of 3 people.

Backlog

TODO

Development
Ongoing

WIP Limit

Done

Testing
Ongoing

Deployment

Done
2

Done

1
B

K
L
M

SAMPLE SELECTED PAGES

133

11.9.4Planning Poker
Planning Poker is also called Estimation Poker. This is an estimation technique which uses
consensus to estimate relative sizes of User Stories or the effort required to create them.
In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in a
sequence and the numbers represent complexity of the problem, in terms of time or effort, as
estimated by the team member. The Product Owner chooses a User Story from the Prioritized
Product Backlog and presents it to the team. The Scrum team members assess the User Story
and try to understand it better before providing their estimate for developing it. Then, each
member picks a card from the deck that represents their estimate for the User Story.

Planning Poker Cards

If the majority or all team member selects the same card then the estimate indicated by that
card will be the estimate for that User Story. If there is no consensus, then the team members
discuss reasons for selecting different cards or estimates. After this discussion they pick cards
again. This sequence continues until all the assumptions are understood, misunderstandings
are resolved and consensus or agreement is reached.
Planning poker advocates greater interaction and enhanced communication among the
participants. It facilitates independent thinking by participants thus avoiding the phenomenon
of the group think.
Fibonacci Sequence
Planning poker cards and Story points are often estimated using the Fibonacci sequence are a
variation of this sequence. The Fibonacci sequence are 0,1,1,2,3,5,8,13 and so on. Each
number is a summation of previous 2 numbers. Teams use Fibonacci sequence to estimate size.
It is a naturally occurring sequence that crops up frequently in connection with how things get
bigger. With this sequence, there is enough variation in the number values to eliminate most of
the discussion over slight difference in estimates. E.g. after 8 story points, the next number is
SAMPLE SELECTED PAGES

136

11.9.7Affinity Estimation
Affinity Estimation is a technique used to quickly estimate a large number of User Stories. Using sticky
notes or index cards and tape, the team places User Stories on a wall or other surface in order from
small to large. The sizes are typically like XS, S, M, L, XL. For this, each team member begins with a
subset of User Stories from the overall Prioritized Product Backlog to place by relative size. This initial
placements is done in Silence. Once everyone has placed their User Stories on the wall, the team
reviews all of the placements and may move User Stories around as appropriate. This second part of the
exercise involves discussion. Finally the product Owner will indicate some sizing categories on the wall.
These categories can be small, medium or large, or they may be numbered using story point values to
indicate relative size. The team will then move User Stories into these categories as the final step in the
process. Some key benefits of this approach are that the process is very transparent, visible to everyone,
and is easy to conduct.

SAMPLE SELECTED PAGES

138

11.9.8Mute Mapping
Mute Mapping is a variant of Affinity mapping where no one speaks and all participants
are invited to stand up and slide cards on the white board.

Exam Pointers

Levels of Planning.
Difference between Iteration and Release planning.
Definition of Agile Modeling
Velocity Based Planning
Simple Numericals on Velocity Based Planning
Kanban Method and Pull System
WIP Limit
Definition of Story Point
Why Story points cannot be compared across teams
Ownership of Story Points
Ideal Days
Triangulating
Planning Poker
Fibonacci sequence in Planning Poker Cards
Fist of Five
Wideband Delphi
Affinity Estimation

SAMPLE SELECTED PAGES

139

EV = 64 story points
AC = 70 story points (we have already used up bandwidth which would be
required to complete 70 story points. i.e. we added one resource extra)
CPI = 64/70 = 0.91
SPI = 64/60 = 1.06
Therefore we are over budget but we are ahead of schedule

12.3.2Cumulative Flow Diagram

Cumulative Flow Diagrams are a wonderful tool to see trends and find bottlenecks in your
delivery process. They are often used in Kanban environments.
Consider the example of a Website Development Project below.
You will see a graph below. It shows the number of user stories in each of you status categories,
for the time period you have selected.
If you draw a horizontal line at any point on this graph you will see a snapshot of your User
Stories on a given date (how many with status Done, TO-DO, Testiing, etc.).
So the CFD is really just a picture of your user stories by status over time. But this picture can
tell you a lot about your development process.

Identifying and eliminating process bottlenecks is a critical element of continuous

improvement.
Example
In the example above, you can see that between August and November suddenly the
backlog has increased in the Deployment stage, which tells that there is some bottleneck
SAMPLE SELECTED PAGES

152

12.4.4Test Driven Development - TDD (XP Practice)

Test-driven development (TDD) is a software development process that relies on the repetition
of a very short development cycle: first the developer writes an (initially failing) automated test
case that defines a desired improvement or new function, then produces the minimum amount
of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck,
who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD
encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme
programming, begun in 1999, but more recently has created more general interest in its own
right.
Programmers also apply the concept to improving and debugging legacy code developed with
older techniques
12.4.4.1 Test-driven development cycle
A graphical representation of the development cycle, using a basic flowchart

The following sequence is based on the book Test-Driven Development by Example.

SAMPLE SELECTED PAGES

159

13.3Retrospectives
The Retrospective is the event in Agile which brings in the iterative, inspective and adaptive
nature into picture. The team reflects upon the previous timebox with a view to learn some
lessons, adjust the behavior or environment in order to improve their experience.
A Retrospective is a special meeting that takes place after each iteration, in which the team
members gather to inspect and improve their methods and teamwork.
Since Retrospectives happen during the project, the lessons and improvements that result from
them are applicable and relevant to upcoming work on the same project.
Advantages of Retrospectives include the following

Improved Productivity : By applying lessons learned and reducing rework, the team can
get more productivity work done.
Improved Capability : Retrospectives provide a venue for spreading knowledge, so does
the number of people who can perform tasks associated with the knowledge.
Improved Quality : We can improve quality on our projects by finding the circumstances
that led to defects and removing the causes.
Improved Capacity : Retrospectives focus on finding process efficiency improvements,
which can improve the team capacity to do work.

13.3.1What is a Retrospective?
Retrospectives are important because they gives the team visibility into issues and helps them
to take action to correct course and make work environment more efficient and more
productive.
Retrospective is a 1-3 hour meeting at the end of the Sprint/Iteration.
Typically, this meeting is held after the Sprint/Iteration Review Meeting. This helps the
team to review what is working and what is not.
Two main questions are asked in the sprint retrospective: What went well during the
sprint? What could be improved in the next sprint?
Team then can take actions going forward
All team members reflect on the past sprint
Make continuous process improvements
Mandatory attendees are Scrum Master and the Teams. Sometimes you may invite the
Product owner also.
To bring in a neutral viewpoint, you may want to bring in a unbiased attendee also such
as a Scrum Master of another team

SAMPLE SELECTED PAGES

170

13.5Useful XP Practices advocating Continuous Improvement

13.5.1Refactoring (XP Practice)
Refactoring is a code cleanup activity. Extreme programming advocates refactoring. Refactoring
is basically a change to the code without changing the interfaces, inputs or outputs. The
purpose of this activity could be any of the following

Improving readability of the Code

Optimize processing logic
Improve maintainability
Improve performance
Comply with design guidelines and framework

Refactoring is a good practice particularly important in Agile as the code gets built
incrementally. It also helps ensure that we are building on top of a firm foundation.
The team should write refactoring stories and request the Product Owner to prioritize them
based on the urgency.

13.5.2Pair Programming (XP Practice)

Pair Programming refers to a practice where 2 peple
share a terminal while working on a task.
One Person is a active programmer (Driver)
Second Person is a active reviewer (Navigator)
While the programmer is coding, the other
participant thinks about strategies, looks for potential
problems for better implementation.
At the face value, it might seem wasteful to have 2
people work on assignment instead of one.
Research also suggest that it results in 15% less throughput, but this is more than compensated
by
Better Quality
Better Upfront Design
Helps ensure succession Planning
Ensures that each line of code or piece of work is seen by more than 1 person
Also it is a great way to train new comers in the team
This technique is especially useful in someone working on extremely complex problems and
debugging hard to solve problems.

SAMPLE SELECTED PAGES

176

SECTION IV Advanced Agile

Concepts

SAMPLE SELECTED PAGES

200

18 Distributed Agile Teams

Today businesses are shifting to emerging economies (such as India) due to reduced business
operations cost and an easily available workforce. The businesses certainly are more virtual and
distributed, with "distributed" as its key element. Thus the need for better managing such
teams, using the right tools and processes, is becoming increasingly critical for any enterprise
company.
Here are some reasons for the shift and need for having distributed Agile teams:

Globally distributed teams reduce costs.

They can reach the market more quickly with a "follow the sun" model.
Distributed teams expand access to new markets.
Acquisitions as a result of consolidation results in companies working together to
integrate their businesses.
Expansion can aid innovation and thought leadership.
Telecommuting gives options for communicating with teams effectively.
Collaboration tools -- improved tools for distributed communications and server-based,
multiuser tools for product development -- are removing barriers, and more teams view
distributed collaboration as an alternative.

18.1Handling Distributed Agile Teams

Distributed teams increase the need for clear, timely communication between sites. You
might be thinking of increases in complexity due to more time zones, language barriers,
and cultural differences getting in the way.

Communication is the core issue among the distributed teams. Different time zones,
conflicting working hours, cultural and language barriers impact communication and
collaboration.
Investing in effective enterprise tools for requirements repositories, source Control
management, build and deployment setup, defect tracking, and project management
tools is essential.
Practicing Test Driven Development (TDD), Continuous Integration and Automation of
Testing are recommended
Proper communication setup such as telephones and videoconference are essential in a
distributed setup.
Telecommunication etiquettes such as conversation using round-robin technique,
importance of mute etc are essential hence a upfront training or setting ground rules for
telephone etiquette is essential.

SAMPLE SELECTED PAGES

215

it helps with communication for distributed and scaled teams and provides
opportunities to find better ways of completing the user stories.

18.3Handling Daily Stand up for Distributed Teams

Using the 3 questions effectively: The Product Owner and Scrum Master should
highlight the importance of the three questions in front of the team members so they
understand their purpose. Team members should communicate information that brings
value to others on the team. They should also try to identify team members who can
help them resolve their issues.
Resolving blockers: The Scrum Master should create a list of blockers and assign them
to team members or managers. The Scrum Master should also ensure the team is
burning through the blocker list.
Daily Scrum logistics: Conducting the daily Scrums when team members are in the same
time zone and speak the same language is much simpler than for a team with members
spread in multiple countries and time zones, having many different languages and
cultures.
o Ways of communicating during the daily Scrum: Having face-to-face daily Scrum
meetings gives the team the highest level of collaboration possible.
o Teleconference meeting: Distributed teams with overlapping work hours should
use a teleconference call to the same phone number every day to hold their daily
Scrum meetings.
o Videoconference meeting: The main advantage of this approach is that team
members get to see one another, so there is less nonverbal communication loss.
o Approach to handling time zone issues: Distributed teams can use methods
such as Daily Scrums through documentation, liaison approach, alternating
meeting times, and share the pain to deal with distributed daily Scrums where
the team has members with no overlap in their work hours.
o Background noise can be distracting on a teleconference, so teams should chose
a quiet room to conduct the meeting.
o Keeping the team engaged: Possibly the best way to stay engaged and to make
sure that others on the team stay engaged is awareness i.e. build awareness of
what the team is working on.
o Facilitating the meeting: In a distributed environment, as individuals come into
the call, they will identify who they are. The Scrum Master calls each person and
asks for their response. They may respond in the order they arrived at the
teleconference or the Scrum Master may choose to call on each person.

SAMPLE SELECTED PAGES

218

100-Point Method, 77
Acceptance Criteria, 95
Acceptance Test-Driven Development, 26
Adjourning. See Tuckman's Ladder Theory
Affinity diagram, 100
Affinity Estimation, 138
Affinity mapping. See Mute Mapping
Agile Charter. See Charter
Agile Contracting, 211
Agile Earned Value Techniques. See Earned
Value Techniques
Agile Games, 101
Agile Modelling, 127
Agile Smell, 156
Architecture Envisioning, 128, See Agile
Modeling
ATDD. See Acceptance Test Driven
Development
Backlog refinement. See Grooming
BCR. See Benefit Cost Ratio
Benefit Cost Ratio, 145, 146
Brainstorming, 100, 173
Burn Up Chart, 153
Burndown chart, 153
Business Value Delivered Chart, 107
CFD. See Cumulative Flow Diagrams
Charter, 88
Chicken and Pig Role, 50
Cockboard Taskboard. See Kanban Board
cone of silence, 196
Configuration Management, 157, 158
Conflict Management, 191
Continuous Integration, 28, 157, 175, 177,
182, 215, 219
Control Charts, 155
Control Limits for Agile Projects. See Control
Charts
CRC Cards, 178
Cumulative Flow Diagram, 152
Customer-valued prioritization, 76
Cycle Time, 134, 145, 148, 149

Daily Scrum, 62
decision making. See Participatory Decision
Models
Development Team, 50, 51, 52, 53, 54, 55,
58, 59, 61, 89, 90, 92, 188
Distributed Agile Teams, 215
Document
Continuously.
See
Agile
Modeling and XP
Document Late. See Agile Modeling and XP
Done Criteria, 59, 100
DSDM, 14, 26, 28, 31, 77, 211
DSDM contract. See Agile Contracting
Earned Value Techniques, 146
Electronic Taskboards. See Kanban Board
Empirical Process Control, 44, 52, 53, 55,
145, 188
Empowered Teams, 55
Epics, 90, 93, 98
Escaped Defects, 145, 149
Excel Spreadsheet Printout Taskboard. See
Kanban Board
Executables Specification, 128, See Agile
Modeling
Extreme programming, 176
Extreme Programming, 26, 27, 28
FDD. See Feature Driven Development
Feature, 98
Feature Driven Development, 111
Fibonacci, 136
Fishbone diagram, 173
Fist of Five, 137, 140, 141, 173
Fixed Price Work Packages. See Agile
Contracting
Forming. See Tuckman's Ladder Theory
Fractional assignment, 196
Free-for-all. See Brainstorming
Graduated Fixed Price. See Agile
Contracting
grooming, 65
ground rules, 171, 186, 191, 215
Idea/mind mapping, 100

SAMPLE SELECTED PAGES

226

Ideal days, 135, 140

Ideal Time. See Ideal Days
Internal Rate of Return, 145
Interpersonal Skills, 115, 192
INVEST, 94
IRR. See Internal Rate of Return
Ishikawa diagram. See Fishbone Diagram
iteration, 13, 30, 31, 35, 36, 46, 59, 61, 64,
92, 94, 104, 108, 109, 110, 124, 125, 130,
131, 145, 146, 149, 153, 202, 203, 204,
207, 209, 212
Iteration Modelling, 128, See Agile
Modeling
iterations, 13, 26, 30, 35, 60, 64, 108, 109,
110, 153, 212
Just Barely Good Enough. See Agile
Modeling
Kaizen, 13
Kanban, 103, 104, 132, 141, 152, 163, 164,
179
Kanban Boards, 104
Kano Model, 77, 78, 82
Laminated Poster Taskboards. See Kanban
Board
Lean Management, 33, 79, 132
Lean principles. See Lean Management
Look Ahead Modelling. See Agile Modeling
Maslows Theory of Hierarchy of Needs. See
Organizational Theories
McGregors Theory of X and Y. See
Organizational Theories
Meta Scrum. See Scrum of Scrums
Metaphor, 28, 39, 175, 177
Minimum Marketable Feature, 80, 98
MMF. See Minimum Marketable Feature
Model Storming. See Agile Modeling
Money for Nothing and Your Change for
Free. See Agile Contracting
Monopoly Money, 77
MoSCoW, 28, 76, 83
MOSCOW, 14
Motivation Theory by Herzberg. See
Organizational Theories

Move people around, 178

Multicriteria decision analysis, 101
Mute Mapping, 139
Net Present Value, 145
Nico Nico Calendar, 110
Nominal group technique, 100
Norming. See Tuckman's Ladder Theory
Organizational Theories, 189
Osmotic communication, 192
Pair Programming, 28, 175, 176, 207
Paired Comparison, 78
pareto, 23
Parking Lot Diagram, 111
Participatory Decision Models, 191
Payback Period, 146, 147
Performing. See Tuckman's Ladder Theory
Personas, 99
Planning Poker, 136
Present Value, 145, 147
Process Analysis. See Agile Modeling
product backlog, 58, 59, 65, 89, 90, 92, 130,
135, 148, 212
Product Backlog, 51, 52, 54, 58, 59, 61, 77,
89, 90, 91, 92, 93, 98, 99, 100, 134, 136,
138
Product Owner, 13, 47, 50, 51, 52, 53, 55,
58, 59, 63, 64, 89, 90, 93, 94, 99, 100,
115, 126, 131, 136, 176, 188, 189, 205
Product Roadmap, 89
progressive elaboration, 125
Prune the Product Tree, 101
Pull. See Kanban
Quiet Time. See Brainstorming
Refactoring, 28, 37, 175, 176, 183
Relative Prioritization, 78, 83
Remember the Future, 101
Requirements Envisioning. See Agile
Modeling and XP
Retrospective, 63, 170, 171, 207
Risk adjusted Product Backlog, 203
Risk Burndown Chart, 207
risk management, 202, 204
risk register, 202

SAMPLE SELECTED PAGES

227

Rolling Wave. See Progressive Elaboration

Round-Robin. See Brainstorming
RTF. See Running Tested Features
Running Tested Features, 145, 146
Sailboat. See Speedboat
Scrum, 8, 13, 26, 33, 42, 44, 45, 46, 47, 50,
51, 52, 53, 54, 55, 56, 58, 59, 60, 61, 62,
63, 64, 65, 70, 77, 87, 90, 109, 110, 115,
134, 136, 137, 157, 170, 188, 189, 204,
205
Scrum Master, 52, 53, 65, 170
Scrum of Scrums, 65, 216, 219
self-pulling system, 36
servant leader. See Servant Leadership
Servant Leadership, 51, 195
Single Source Information. See Agile
Modeling and XP
Situational Leadership Model., 187
Speedboat, 102
spike, 96, 158, 163, 164
Sprint, 45, 46, 47, 48, 54, 55, 60, 61, 63, 64,
87, 91, 169, 170, 171, 188, 205, 206, 207
sprint backlog. See Product Backlog
Sprint Backlog, 58, 61
sprint burndown chart. See Burndown Chart
Sprint Retrospective. See Retrospective
Storming. See Tuckman's Ladder Theory
Story Card, 96
Story Points, 134
Street Light, 108

Sustainable pace, 195

Swarming, 97
Systems thinking, 180
task board, 58, 91, 92, 104, See Kanban
Board
Taskboards. See Kanban Board
TDD. See Test-driven development, See
Test-driven development
Team Spaces, 196
Technical Debt, 177
Test-driven development, 33, 159
Themes, 99
Timebox, 29, 60, 61, 76
Triangulating, 135
Tuckmans Ladder Theory, 186
User Story, 59, 78, 93, 94, 95, 96, 100, 134,
136, 206
Value stream mapping, 79
Velocity, 108, 109, 110, 130, 134, 140, 141,
145, 148, 151
Velocity Charts, 108, 109
Vision Statement, 89
Voice of Customer, 52
Wideband Delphi, 137
WIP. See work in progress, See work in
progress, See work in progress
WIP limit. See work in progress
wireframe, 113, 114
work in progress, 112, 132, 133
XP. See Extreme Programming

SAMPLE SELECTED PAGES

228

SAMPLE SELECTED PAGES

229