Agile Training Module

Training Module

Preface
December 2019

© 2019 IBM Corporation

1
Agile Training Module

Table of Contents
Chapter 1: What is a project? ...........................................................10
1.1 Definition of Project ........................................................................... 10
1.2 Project vs Operations ......................................................................... 10
1.3 Relationship between Project, Program, Portfolio ............................ 11
1.4 Features of Project ............................................................................. 14
1.5 Measuring Project Success.............................................................. 16
1.6 Phases of a Project............................................................................. 17
Initiation............................................................................................... 18
Definition .............................................................................................. 18
Planning ............................................................................................... 19
Execution ............................................................................................. 19
Monitoring & Control ............................................................................ 19
Closure ................................................................................................. 19
Exercise 1: ................................................................................................ 20
Test Your Knowledge ............................................................................... 22
Chapter 2: Project Execution Methodologies .....................................24
2.1 Waterfall Model ............................................................................... 24
2.1.1 How does Waterfall work? ...................................................... 24
2.1.2 Where is Waterfall model suitable? ........................................ 26
2.1.3 Advantages, Disadvantages of Waterfall Model ..................... 27
2.2 V-Model............................................................................................ 28
2.2.1 How does V-Model work? ....................................................... 30
2.2.2 Where is V-model suitable? .................................................... 30

© 2019 IBM Corporation

2
Agile Training Module

2.2.3 Advantages, Disadvantages of V-Model ................................. 31

2.3 Agile ................................................................................................. 32
2.3.1 How does Agile works? ........................................................... 32
2.3.2 Where is Agile suitable............................................................ 33
2.3.3 Advantages, Disadvantages of Agile....................................... 33
Test Your Knowledge ............................................................................... 36
Chapter 3: Agile Deep Dive ..............................................................37
3.1 Agile Methodology Overview ........................................................... 37
3. 2 Introduction to Agile Manifesto & Guiding Principles .................. 39
3.3 Roles within Agile Team ............................................................... 41
3.4 Agile vs Waterfall ............................................................................. 54
3.5 Agile Frameworks ............................................................................ 57
3.6.1 Extreme Programming (XP) .................................................... 57
3.6.2 Rational Unified Process (RUP) .............................................. 62
3.6.3 Feature Drive Development (FDD) .......................................... 65
3.6.4 Test Driven Development (TDD) ............................................. 67
3.6.5 Scrum ...................................................................................... 71
3.6.6 Kanban .................................................................................... 72
Agile Certifications: .................................................................................. 74
Exercise 1: ................................................................................................ 75
Test Your Knowledge ............................................................................... 76
Chapter 4: Scrum – Deep Dive ..........................................................78
4.1 Foundations of Scrum ..................................................................... 78
4.2 Scrum Diagram ................................................................................ 79
4.3 Scrum Team ..................................................................................... 80

© 2019 IBM Corporation

3
Agile Training Module

4.4 Roles in Scrum Team ....................................................................... 81

4.5 Sprints .............................................................................................. 83
4.6 Definition of Ready .......................................................................... 83
Test Your Knowledge ............................................................................... 84
Chapter 5: Scrum Artifacts ...............................................................85
Product Backlog ....................................................................................... 85
Sprint Backlog .......................................................................................... 86
Sprint Burndown chart ............................................................................. 88
Impediments List ..................................................................................... 89
Product Increment ................................................................................... 89
Test Your Knowledge ............................................................................... 90
Chapter 6: Scrum Ceremonies..........................................................91
6.1.1: Sprint Planning............................................................................... 91
When should you do sprint planning ................................................... 91
Topic One: What can be done this Sprint? .......................................... 91
Topic Two: How will the chosen work get done? ................................ 92
Why is Sprint planning important? ...................................................... 93
What should happen during sprint planning? ..................................... 93
Sprint Planning Template .................................................................... 94
6.1.2: Daily Scrum Meeting ...................................................................... 95
Daily scrum meeting Preparation ........................................................ 96
Purpose of daily scrum: ....................................................................... 97
Importance of Daily Scrum Meeting: ................................................... 97
Daily Stand-up Characteristics ............................................................ 97
Daily scrum meeting template: ........................................................... 98

© 2019 IBM Corporation

4
Agile Training Module

6.1.3: Product Backlog Refinement (PBR)/Grooming ............................. 99

The Objective of PBR meeting: ............................................................ 99
Importance of PBR: .......................................................................... 100
Product Backlog Refinement Flow chart: ......................................... 101
6.1.4 Sprint Review / Demonstration meeting ................................... 103
Sprint Review Meeting: ..................................................................... 104
The Sprint review meeting should include the following: ................ 104
6.1.5 Sprint Retrospective .................................................................. 105
Meeting specifics .............................................................................. 105
How is Sprint Retrospective held? ................................................... 106
Benefits of Retrospective: ................................................................ 107
Tips for effective Retrospective........................................................ 108
Sprint Retrospective Template:........................................................ 108
Exercise 1: Quick recap of Scrum Ceremonies ..................................... 109
Test Your Knowledge: ........................................................................... 111
Chapter 7: Scrum Sprint Planning ..................................................113
7.1 Sprint Goal ...................................................................................... 113
Benefits of Sprint Goal: ..................................................................... 113
Determine Sprint Goal: ..................................................................... 113
Sprint Goal Template ........................................................................ 115
7.2 User Stories ..................................................................................... 116
Definition:.......................................................................................... 116
User Stories Template: ..................................................................... 116
Example: ........................................................................................... 116
Why you should write a user story: .................................................. 117

© 2019 IBM Corporation

5
Agile Training Module

Benefits of writing user stories ......................................................... 117

7.3 Estimate User Stories ..................................................................... 118
What is a Story Point? ....................................................................... 118
Factors to be consider while estimating stories: ............................. 119
Participants in story Point estimation: ............................................. 119
Advantages of using story points for estimating work: .................... 119
Steps to estimate stories .................................................................. 120
7.3 Definition of Done ........................................................................... 122
Story Definition of Done .................................................................... 123
Sprint Definition of Done .................................................................. 123
Release Definition of Done ............................................................... 123
The evolving Definition of Done ........................................................ 124
Definition of Done common impediments........................................ 124
Exercise 2: Effective estimation of User story ..................................... 124
Test Your Knowledge: ........................................................................... 126
Chapter 8: Scrum Metrics ..............................................................127
8.1 Sprint Goal Success ........................................................................ 127
8.2 Team Velocity ................................................................................. 128
Importance of velocity...................................................................... 130
Why do we need velocity? ................................................................ 131
Can an incomplete user story be counted in velocity?..................... 131
Determining team velocity................................................................ 132
8.3 Sprint Burn Down Chart .................................................................. 132
Definition ........................................................................................... 132
What does a Burndown chart show? ................................................ 133

© 2019 IBM Corporation

6
Agile Training Module

Steps to read Burndown chart:......................................................... 134

Samples Burndown chart: ................................................................ 135
Advantages of using Burndown charts: ............................................ 136
Common mistakes while using Burndown charts: ........................... 137
8.4 Defect Density: ................................................................................ 138
Definition:.......................................................................................... 138
Formula to measure Defect Density: ................................................ 138
Example: ........................................................................................... 138
Advantages of defect density ........................................................... 139
Factors that affect the defect density metrics ................................. 139
Exercise 3: Where do I Stand? ............................................................. 139
Test Your Knowledge: ........................................................................... 140
Chapter 9: Additional Info .............................................................141
9.1 Scaling Scrum ................................................................................. 141
Commonly used Scaling frameworks ............................................... 141
LeSS (Large Scale Scrum) ................................................................. 142
Overview of LeSS with synchronized sprints.................................... 143
SAFe .................................................................................................. 145
Process.............................................................................................. 145
Week-by-week, the relationship between Sprints and Program
Increments ....................................................................................... 146
Scrum@Scale .................................................................................... 147
Product Owner cycle......................................................................... 148
Scrum Master cycle .......................................................................... 149
9.2 Distributed Scrum Practices ........................................................... 149

© 2019 IBM Corporation

7
Agile Training Module

Distributed Agile: 10 Good Practices of Successful Teams ............. 150

Meeting face-to-face is the only way to build trust ......................... 150
Establish a shared project vision ...................................................... 151
Establish continuous integration (CI) with high test coverage across
all teams............................................................................................ 151
Establish a synchronization and communication plan ..................... 151
Establish a rigorous Norming and Chartering plan to achieve high
quality ............................................................................................... 151
Use short sprints ............................................................................... 152
ScrumMaster at both locations ........................................................ 152
Execute 3 to 4 sprints with entire team at local site ........................ 152
Go for features teams over component or layer teams ................... 153
9.3 Agile Environments & Tools ............................................................ 153
Agile Environments: .............................................................................. 153
The 10 Characteristics of an Agile Environment .............................. 153
The 7 Steps to Create an Agile Environment .................................... 154
Don’t Forget the Cultural Shift .......................................................... 154
Agile Methodology Tools ....................................................................... 155
1. Active Collab ................................................................................. 156
2. Agilo for Scrum ............................................................................. 157
3. Atlassian Jira + Agile .................................................................... 158
4. Pivotal Tracker .............................................................................. 159
5. SprintGround ................................................................................ 160
9.4 Kanban Vs Scrum: ........................................................................... 161
3 Differences Between Scrum and Kanban...................................... 162

© 2019 IBM Corporation

8
Agile Training Module

How are Scrum and Kanban the same? ........................................... 163

How are Scrum and Kanban different?............................................. 163
Scheduling, iteration, and cadence .................................................. 163
Roles and responsibilities................................................................. 164
9.5 Xtreme Programming Vs Scrum: .................................................... 164
Test Your Knowledge ............................................................................ 165
1. Case Study – I (IT Related).......................................................166
Modernize eLearning Platform for University of ABZ ........................... 166
2. Case Study – II (IT Related) .....................................................166
Blockchain solving fraudulent academic qualifications ....................... 166
3. Case Study – III (Non IT Related) .............................................167
Hosting Worldwide Artificial Intelligence Conference at the Premium
Institute of Delhi ................................................................................... 167
Answer Keys ..................................................................................168
NOTICES ........................................................................................169

© 2019 IBM Corporation

9
Agile Training Module

Chapter 1: What is a project?

1.1 Definition of Project

A project is a series of tasks that need to be accomplished to pursue a

specific result. A project can also be defined as a set of inputs and outputs
required to reach a goal. Projects can range from simple to complex and can
be managed by one person or many. Projects are often described and
delegated by a manager or executive. They go over their expectations and
goals and the team are expected to manage logistics and execute the
project in a timely manner. Sometimes deadlines can be given or a time
limitation.

1.2 Project vs Operations

A project is temporary in nature, having a definite start and end date, and
produces a unique output. Projects are conducted to obtain the
organization’s strategic purposes and are considered above and beyond
normal organizational operations.

Operations, however, are the ongoing, repetitive activities that are involved
in the organization’s primary business. They are activities such as staffing
management, payroll, product production, service delivery, etc. As such,
operations include all the “normal” business functions.

Both projects and operations are:

• Done by people
• Controlled by limited resources (such as people, money, equipment,
and time)
• Planned, executed, and controlled

© 2019 IBM Corporation

10
Agile Training Module

However, projects:
• Are led to attain an objective and then terminate
• Organize activities that are not supported under the organization’s
normal operations
• Are directly associated to the achievement of the organization’s
strategic plan

Whereas operations:
• Are on-going and required to sustain the business

1.3 Relationship between Project, Program, Portfolio

Projects are temporary endeavors to create one or more deliverables.

Programs are larger initiatives that are broken up into a set of smaller
projects and subprograms and then coordinated centrally. The projects in a
program are related to each other.

Portfolios are collections of work (projects, programs, or sub-portfolios)

and are a way to plan and manage the projects from an organization
perspective. The projects may or may not be related.

A portfolio, program, and project- though similar they may sound, their
meaning and usage is quite different. Now that we know what a project is,
let’s look at program and portfolios.

Program

Programs are clustered within a portfolio and comprise of subprograms,

projects, or other work that are managed in a coordinated manner in
support of the portfolio. Programs are so large that they must be broken
down into smaller units (projects or subprogram) to distribute the
responsibilities and ease the work. The process of breaking down the

© 2019 IBM Corporation

11
Agile Training Module

overall work and distributing it to individual project team means multiple

brains in a single program. When several teams and managers present ideas
for their projects, it works well for the different projects but not for the
initiative.

For example, consider an automobile company that manufactures different

types of cars. The design and manufacturing of one type of car would be
called a program and of the parts like bonnet, body or engine would be a
project. The integration of all the parts (projects) would make a complete
car (program).

The objective of a program is to provide central management and control

over a set of underlying projects that are identified to deliver a common
solution. It allows an organization to achieve the benefits that individual
projects cannot achieve alone.

To understand the concept better, observe the diagram. In this, a program

is divided into two projects and a subprogram outside of the scope of both
the projects:

© 2019 IBM Corporation

12
Agile Training Module

Portfolio

A portfolio refers to a group of projects, programs, sub-portfolios, and

operations managed as a group to achieve strategic objectives. A portfolio
includes both projects and programs and is managed by a portfolio
manager. The portfolio is directly drawn from the strategic business plan of
the organization. Important decisions like investment are made at the
portfolio level.

For example, consider the case of an automobile company. The unique

designs of various cars will denote programs, and the design of cars, in
general, will denote portfolio. To understand the concept better, take help
of diagram. In this, a portfolio is divided into one project and two programs
and a sub-portfolio outside of the scope of both the projects:

© 2019 IBM Corporation

13
Agile Training Module

1.4 Features of Project

The distinctive features of a project are as follows:

1. Objectives:
A project has a fixed set of objectives. Once the objectives have been
accomplished, the project concludes.
2. Life Span:
A project cannot continue infinitely. It must come to an end. What
represents the completion would normally be spelt out in the set of
objectives.
3. Single entity:
A project is one entity and is normally entrusted to one responsibility center
while the contributors to the project are many.
4. Team-work:
A project demands for team-work. The team again is constituted of
members from different disciplines, organizations and even countries.
5. Life-cycle:
A project has a life cycle reflected by growth, maturity and decay. It has
naturally a learning component.
6. Uniqueness:
No two projects are exactly similar. The location, the infra-structure, the
agencies and the people make each project exclusive.
7. Change:

© 2019 IBM Corporation

14
Agile Training Module

A project sees many changes throughout its life while some of these
changes may not have any major impact; then- can be some changes which
will change the entire character of course of the project.
8. Successive principle:
What is going to happen during the life cycle of a project is not known
entirely at any stage. The details get finalized continually with the passage
of time. More is known about a project when it enters the construction
phase than what was known, during the detailed engineering phase.
9. Made to order:
A project is always made to the order of its customer. The customer
specifies various requirements and puts constraints within which the
project must be executed.
10. Unity in diversity:
A project is a complex set of thousands of varieties. The varieties are in
terms of technology, equipment and materials, machinery and people, work
culture and ethics. But they remain inter-related and unless this is so, they
either do not belong to the project or will never allow the project to be
completed.
11. High level of sub-contracting:
A high percentage of the work in a project is done through contractors. The
more the complexity of the project, the more will be the extent of
contracting. Normally around 80% of the work in a project is done through
sub-contractors.

12. Risk and uncertainty:

© 2019 IBM Corporation

15
Agile Training Module

Every project has risk and uncertainty associated with it. The degree of risk
and uncertainty will depend on how a project has passed through its various
life-cycle phases. An ill-defined project will have extremely high degree of
risk and uncertainty. There simply cannot be a project without any risk and
uncertainty.

1.5 Measuring Project Success

There are many indicators of project success, but what do you need to be
measuring while the project is in motion?

Let’s look at the five things you should be evaluating.

1. Schedule

Project management success is often determined by whether you kept to

the original timeline or not.

The schedule evaluation is something you can do more formally at the end
of the stage or phase, or as part of a monthly report to your senior
stakeholder group or Project Board.

Look at your major milestones and check if they still fall on the same dates
as you originally agreed. Work out the slippage, if any, and how much of an
impact this will have on your overall project timescales.

2. Quality

The end of a project phase is a good time for a quality review.

A quality review can evaluate whether what you are doing meets the
standards set out in your quality plans. Best find out now before the project
goes too far, as it might be too late to do anything about it then.

© 2019 IBM Corporation

16
Agile Training Module

3. Cost

Many executives would rate cost management as one of their highest

priorities on a project, so evaluating how the project is performing
financially is crucial.

We can look forward and re-forecast the budget to the end of the project.
Comparing this to your original estimate and making sure it is close enough
is important for your management team to feel that the work is on track. If
the forecasts go up too much it is a sign that the spending will be out of
control by the end of the project.

4. Stakeholder Satisfaction

Stakeholders – are essential in getting much of the work done. Finding out
how they feel about the project at present and what you could be doing
differently is worth checking.

5. Team satisfaction

This is more subjective in nature and is often overlooked when evaluating

project success. But, team satisfaction should be at the top of your success
criteria as they’re the ones who are the key not only to the current project
success but to the future projects too. They also have deeper insights that
even the top stakeholders may not have.

1.6 Phases of a Project

Projects are divided into six stages:

• Initiation
• Definition
• Planning

© 2019 IBM Corporation

17
Agile Training Module

• Execution
• Monitoring & Control
• Closure

Each project stage is characterized by a distinct set of tasks that take the
project from the first idea to its conclusion. Each stage is of equal
importance and contributes to the overall success of the project.

Initiation
This is perhaps the most important stage of any project as it sets the terms
of reference within which the project will be run. If this is not done well, the
project will have a high likelihood of failure. The initiation stage is where the
business case is declared, scope of the project decided, and stakeholder
expectations set. Time spent on planning, refining the business case and
communicating the expected benefits will help improve the probability of
success. It is tempting to start work quickly, but a poor initiation stage often
leads to problems and even failure.

Definition
Before a project begins, the Project Manager must make that the project
goals, objectives, scope, risks, issues, budget, timescale and approach have

© 2019 IBM Corporation

18
Agile Training Module

been defined. This must be communicated to all the stakeholders to get

their agreement. Any differences of opinion must be resolved before work
starts.

Planning
The key to a successful project is in the planning. Creating a project plan is
the first task that should be done while undertaking any project. Often
project planning is ignored in favor of getting on with the work. However,
many people fail to realize the value of a project plan in saving time, money
and for avoiding many other problems.

Execution
This is where the work to deliver the product, service or wanted result is
carried out. Most of the work related to the project is realized at this stage
and needs complete attention from the project manager.

Monitoring & Control

Once the project is running it is important the project manager keeps
control. This is achieved by regular reporting of issues, risks, progress and
the constant checking of the business case to make sure that the expected
benefits will be delivered and are still valid.

Closure
Often neglected, it is important to make sure the project is closed properly.
Many projects do not have a clear end-point because there is no formal
sign-off. It is important to get the customers’ agreement that the project
has ended, and no more work will be carried out. Once closed, the project
manager should review the project and record the good and bad points, so
that in the future, successes can be repeated, and failures avoided. A
project that is not closed will continue to consume resources.

© 2019 IBM Corporation

19
Agile Training Module

Exercise 1:

Introduction: This exercise will check your understanding of what a project

is and its various aspects

Procedure:
• Divide the entire team into 4 sub-groups.
• Ask each group to identify themselves as a company
• Give one-one chart paper, Markers to each sub team
• Ask the participant to divide the entire sheet into 4 quarters like
below.
• In each box, as the team to fill what they think from their company
perspective would fall into each of these boxes.

Project: Operation:

Program: Portfolio:

© 2019 IBM Corporation

20
Agile Training Module

• Give 5 Mins for discussion

• After that give 10 mins to fill the chart
• Call any one of the sub team to display their thoughts in the board
and explain the categorization.
• Ask other teams at the end if the team missed out any point
• Likewise call each team to explain their thoughts.

Logistics: 1 Display board

4 chart papers
8-10 Markers (Each Team 2 different color Markers)

© 2019 IBM Corporation

21
Agile Training Module

Test Your Knowledge

1. A project is;
a. an activity to meet the creation of a unique product or service
b. activities that are undertaken to accomplish routine activities
c. series of tasks that need to be completed to reach a specific
outcome.
d. A and C
e. A and B

2. A university wanted to build admissions websites for all its

departments. It realized that all the sites would be feeding into the
same registration interface and decided to manage all of them
together. Is this a
a. Program
b. Portfolio
c. Project

3. A company wanted to build a better reporting interface that it could

have more accurate data on year- end goals. Is this a
a. Program
b. Portfolio
c. Project

4. Watering plants twice a week. Is It a

a. Project
b. Program
c. Operation

5. What is project lifecycle?

a. A series of phases a project passes through from initiation to
closure.
b. Everything from project start to project finish.

© 2019 IBM Corporation

22
Agile Training Module

c. When a project is about to complete, it starts a new project to

shift the work to the next generation of deliverables.
d. Don’ know

© 2019 IBM Corporation

23
Agile Training Module

Chapter 2: Project Execution

Methodologies

2.1 Waterfall Model

The Waterfall Model is a linear or sequential approach to project
management and works based on fixed dates, requirements, and
outcomes. Teams do not require consistent communication and, unless
specific integrations are required, can be self-contained. Team members
can also work independently and are often required to provide status
reports somewhat less frequently (when compared to an agile approach).

2.1.1 How does Waterfall work?

A typical Waterfall project is chronological and is made up of the following
phases:
• Requirements
• Design
• Implementation
• Verification
• Maintenance

© 2019 IBM Corporation

24
Agile Training Module

Let’s break this down.

Requirements
Throughout these five stages, written requirements, usually put into a
single document and used for verification of each stage, are composed
alongside constraints and functional and non-functional needs of the
project. Cost is described, as are assumptions, risks, dependencies,
success metrics, and timelines for completion.
Design
A high-level design (HLD) is created to describe the purpose, the scope of
the project, the general traffic flow of each component, and the integration
points (the topology), followed by a detailed design, which allows subject
matter experts (SMEs) to implement the HLD design to precise details.

© 2019 IBM Corporation

25
Agile Training Module

Implementation
Implementation teams work to the design to create, code, implement, and
test the solution. It is crucial that the single written document be as clear
as possible, as the team who designs the system may or may not be the
same. If changes are required during the implementation phase (due to
unforeseen issues with the design, integrations, or even changes to the
intended function of the system), this necessitates that a new design be
created and signed off on before the implementation is completed.
Verification
Acceptance tests are then deployed and executed in the verification phase,
with the built solution further tested against the requirements to confirm
that the project meets initial expectations. If it does not, then an
examination is performed to identify the shortfalls and a review is
completed to determine any ratification actions.

Maintenance
Finally, as defects are raised, or new versions of products are needed
(maybe because they are no longer supported), planned changes are made
by a dedicated ownership team. With the Waterfall Model, each stage can
only continue when each of the previous stages are completed and signed
off.

2.1.2 Where is Waterfall model suitable?

The Waterfall Methodology has been widely used in the past to get projects
completed against a deadline, at a given cost, and to a predefined quality.
• This model is used only when the requirements are very well known,
clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements

© 2019 IBM Corporation

26
Agile Training Module

• Ample resources with required expertise are available freely

• The project is short.

In Waterfall model, very less customer interaction is involved during the

development of the product. Once the product is ready then only it can be
demonstrated to the end users.
Once the product is developed and if any failure occurs then the cost of
fixing such issues are very high, because we need to update everything from
document till the logic.

2.1.3 Advantages, Disadvantages of Waterfall Model

As with most methodologies, the Waterfall Model comes with just as many
benefits as constraints that can impact a project. Let’s look at some of the
benefits and constraints you will need to balance with getting your project
out of the door.
Advantages:
• The project scope stays relatively static, meaning cost and timelines
can be determined early in the project.
• By completing a full design early in the project, changes to systems
stay minimal, meaning the cost to fix and alter designs is kept low.
• A structured approach to a project means that everyone understands
what needs to be done and when. SMEs can effectively plan their time
over the fixed period.
• By having detailed documentation and designs, a project can lose key
members without too much hassle since the documentation
describes in reasonable detail how any SME of the product or skill are
needed to complete the work.

© 2019 IBM Corporation

27
Agile Training Module

Disadvantages:
• It is hard to allow for new requirements in an ever-changing world.
For example, an organization or industry-wide change of
specifications would take a long time to adopt, with the project
needing to return to the requirements and design stage.
• A project that has dependencies on relatively unstable products
which are constantly in flux may also cause constraint. For example,
if the project makes use of software or technologies with very rapid
release-cycles and paces-of-change, then the project needs to have
fixes being implemented monthly. This makes design and
documentation very difficult and means risk and assumptions must
be embedded into the estimations with widely varying degrees of
accuracy.
• It is difficult to estimate the total time a project will take to complete.
Each organization has different processes and each project has
different issues, including SME shortages, long delays in provisioning
software, and a lengthy approval process.
• A large amount of contingency is often added into timescales. From
the start of project, lots of subjects and outcomes will be
undetermined and only put into production in the final stages of the
project. This creates risk, which gradually diminishes as the project
progresses. Whilst this risk can be decreased with good practices, it
still creates a good deal of uncertainty.

2.2 V-Model

The V-model is a model where process executes in a sequential manner in

V-shape. It is also known as Verification and Validation model. It is based
on the association of a testing phase for each corresponding development
stage. Development of each step directly associated with the testing phase.
The next phase starts only after completion of the previous phase i.e. for

© 2019 IBM Corporation

28
Agile Training Module

each development activity, there is a testing activity corresponding to it.

Verification: It involves static analysis technique (review) done without

executing code. It is the process of evaluation of the product development
phase to find whether specified requirements meet.

Validation: It involves dynamic analysis technique (functional, non-

functional), testing done by executing code. Validation is the process to
evaluate the software after the completion of the development phase to
determine whether software meets the customer expectations and
requirements.

So, V-Model contains Verification phases on one side of the Validation

phases on the other side. Verification and Validation phases are joined by
coding phase in V-shape. Thus, it is called V-Model.

© 2019 IBM Corporation

29
Agile Training Module

2.2.1 How does V-Model work?

The V-model provides guidance that testing needs to begin as early as

possible in the life cycle. It also shows that testing is not only an execution-
based activity. There are a variety of activities that need to be performed
before the end of the coding phase. These activities should be carried out
in parallel with development activities.

2.2.2 Where is V-model suitable?

V-model is suitable when:

• used for small to medium sized projects where requirements are

clearly defined and fixed.
• chosen when ample technical resources are available with needed
technical expertise.
• Where requirements are clearly defined and fixed.
• The V-Model is used when ample technical resources are available
with technical expertise.

© 2019 IBM Corporation

30
Agile Training Module

High confidence of customer is required for choosing the V-Shaped model

approach. Since, no prototypes are produced, there is a very high risk
involved in meeting customer expectations.

2.2.3 Advantages, Disadvantages of V-Model

Advantages
• This is a highly disciplined model and Phases are completed one at a
time.
• V-Model is used for small projects where project requirements are
clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the
life cycle thereby enhancing the probability of building an error-free
and good quality product.
• It enables project management to track progress accurately.

Disadvantages
• High risk and uncertainty.
• It is not a good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and
contains high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events.

© 2019 IBM Corporation

31
Agile Training Module

2.3 Agile
AGILE methodology is a practice that promotes continuous iteration of
development and testing throughout the software development lifecycle of
the project. Both development and testing activities are concurrent unlike
the Waterfall model.
Agile development enables teams to work quickly and efficiently by
creating clear goals and a standard way of working. Your team even has the
option to choose between several frameworks within Agile project
management.

2.3.1 How does Agile works?

The agile approach basically involves a number of cycles usually called
‘sprints’ that are designed, developed, and tested individually.

© 2019 IBM Corporation

32
Agile Training Module

Simply, consider each sprint to be a miniature project having its own

backlog, design, development, testing, and deployment phases within the
pre-defined scope of work.
At the end of each sprint, a potentially deliverable product is shipped. In
simple terms, with every iteration completion, new features are added to
the main software which results into the software growth.

2.3.2 Where is Agile suitable

The most appropriate projects for agile are ones with aggressive deadlines,
a high degree of complexity, and a high degree of novelty (uniqueness) to
them.

Examples of projects where Agile is suitable or may be possible:

• Small to medium-sized software developments.

• Product development where multiple variants are required or
desirable.
• Where the main deliverable can be broken down and produced (and
even potentially released or at least accepted by the end customer) in
incremental discrete packages. There is one major consideration here
though; the requirements and functions developed during each
iteration must be stand-alone and not have major dependencies with
other requirements and functions outside of the current iteration. At
the end of the iteration, we should have elements of product that are
ready to release and deploy. If we cannot achieve that, we may not
be using Agile at all.
Also, anywhere you find very dynamic requirements, which are able or likely
to evolve per iteration, could take advantage of a more Agile approach.

2.3.3 Advantages, Disadvantages of Agile

Now, let’s explore some of the benefits and constraints you may run into
from using Agile practices on your next project.

© 2019 IBM Corporation

33
Agile Training Module

Advantages:
• Agile projects deliver quickly.
• New requirements can be swiftly incorporated into the design, the
team, and priorities.
• There is stakeholder engagement throughout the development
process to review and improve the products and projects being
delivered.
• Transparency and openness are encouraged with a focus on
improvement over blame.
• Projects that aren’t successful can quickly be contained, repaired, or
retired entirely to save money.
• Defects and required enhancements are caught early because
changes are tested over small iterations. These are picked up and
added to future sprints in the sprint planning phase (for the Scrum
method) or added into the backlog based on importance for next
delivery by the team (for the Kanban method).
• Teams can adapt how they work, providing a more productive and
satisfactory working environment by portraying mood and
highlighting issues in retrospective sessions.
• Documentation is less time consuming and costly because it is limited
to use cases, test cases, user stories, and other artefacts over
detailed product documentation. Documentation as a result, is leaner
and more concentrated, although admittedly less detailed.

Disadvantages:
• Agile projects can be chaotic if not managed well or if the team does
not engage in the practices.
• Documentation can become quickly and easily out of date where
teams have little time to write it over, reducing defects. This makes it
hard for new team members to get up to speed and increases the
number of duplicated conversations and confusion over why
decisions were originally made.

© 2019 IBM Corporation

34
Agile Training Module

• A lot of time is spent in scrums, retrospectives, sprint planning, mood

discussions, and stakeholder meetings which can strain time and
money.
• If there is no clear end-goal, scope can forever increase with no
defined measurement of success.
• Good design is delayed in preference of quickly adding new features.
This can lead to extra work in the long run because functionality that
hasn’t been thoroughly worked out may receive negative feedback
and increase defects as more users start to use them.
• With teams that are highly knowledgeable about their specific
projects, members cannot always be easily replaced with low cost
resources, which can be essential to keeping a project in budget. This
inability to outsource can cause significant headaches for
organizations with low cost thresholds. This also relates to teams
needing to be entirely remote or entirely co-located, which can limit
the available resource pool.

© 2019 IBM Corporation

35
Agile Training Module

Test Your Knowledge

1. A model that is the demo implementation of the system.
a. Prototype
b. Waterfall
c. Incremental
d. Agile

2. Maintenance is the final phase in waterfall model.

a. True
b. False

3. A stage in which individual components are integrated and ensured that

they are error-free to meet customer requirements.
a. Testing
b. Coding
c. Design
d. Implementation

4. What do you call a technical person who can understand the basic
requirements?
a. team leader
b. analyst
c. engineer
d. stakeholder
5. Which of these are benefits of V model
a. Simple and easy to use.
b. Each phase has specific
c. reduces the cost of bug fixes
d. Works most effective with small projects where requirements are
small
e. All the above.

© 2019 IBM Corporation

36
Agile Training Module

Chapter 3: Agile Deep Dive

Now that we have understood the basics of Agile, where it’s suitable and its
advantages and disadvantages, let’s get into the understanding Agile in
more detail.

3.1 Agile Methodology Overview

Agile methodologies have helped many organizations to respond quickly to
the changing market conditions, increase customer satisfaction, and
improve overall productivity.
But, there are still lots of organizations that are facing difficulties in
understanding and implementing Agile.
Agile is a way to manage projects. While agile approach can be used for
virtually anything, it was originally founded in software development
company India.
Agile approach allows business analysts, designers, developers, and
stakeholders to work together at the same time. It basically breaks large
projects into small iterations. And, at the end of each iteration, something
of great value is produced.
The agile approach basically involves a number of cycles usually called
‘sprints’ that are designed, developed, and tested individually

© 2019 IBM Corporation

37
Agile Training Module

Consider each sprint to be a mini project having its own backlog, design,
development, testing, and deployment phases within the pre-defined
scope of work.
At the end of each sprint, a potentially deliverable product is shipped. In
simple terms, with every iteration conclusion, new features are added to
the main software which results into the software growth.

Agile methodologies have five steps that have their own outcome. Agile
Methods are being widely accepted in software world recently, but it is not
suitable for all products.
1. Planning: During planning, research about the existing systems will be
done to identify the problem that user has. Developer must classify
the problem statement and find the best solution to solve the
problem.

2. Design: During design, a high-level architecture to low level

programming is defined based on the user inputs.

© 2019 IBM Corporation

38
Agile Training Module

3. Coding: The team works to develop a working software based on the

iteration requirements and feedback.

4. Testing: Testing is phase to test the system after process planning

and design. The advantages of using Agile Method are, developer can
return to any phase that needs to repair without having to go back to
first stage.

5. Implementation: During this phase, the final iteration of the product

is released on production.

3. 2 Introduction to Agile Manifesto & Guiding Principles

The "Agile Manifesto" dates to 2001, when software development practices
were not like today. During those days, it was typical to spend a year
planning and writing specifications and another year writing and testing
code. By the time any software was shipped, it was already 2 years behind
what customers were looking for.

According to the manifesto, an agile culture values individual, interactions,

working software, collaboration with customers, and response to change.
The principles of the Agile Manifesto can guide teams to define, design,
develop, and deliver innovative solutions across the entire lifecycle, roles,
and disciplines.

Your team or organization can expand on those principles depending on its

experience with other practices and methodologies, like Enterprise Design
Thinking and Lean Start-up, but the manifesto and principles have proven
themselves for more than 14 years.

Four values of Agile

The four core values of Agile software development as stated by the Agile
Manifesto are:

© 2019 IBM Corporation

39
Agile Training Module

• individuals and interactions over processes and tools;

• working software over comprehensive documentation;
• customer collaboration over contract negotiation; and
• responding to change over following a plan.

12 Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need and trust them to get the job
done.
6. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity--the art of maximizing the amount of work not done-
-is essential.
11. The best architectures, requirements, and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behaviour accordingly.

© 2019 IBM Corporation

40
Agile Training Module

Proponents of Agile methodologies say the four values outlined in the Agile
Manifesto promote a software development process that focuses on quality
by creating products that meet consumers' needs and expectations.

The 12 principles are intended to create and support a work environment

that is focused on the customer, that aligns to business objectives, and that
can respond and pivot quickly as user needs and market forces change.

3.3 Roles within Agile Team

At its core, Agile development enables teams to work quickly and efficiently
by creating clear goals and a standard way of working. Your team even has
the option to choose between several frameworks within Agile project
management.
A few, key fundamental aspects of an Agile team include:
Communication between team members, management, and cross team to
discuss rapid change.
Introspective opportunities, or team retrospectives, where team members
can discuss what went well, what went poorly, and what needs
improvement.
A flexible, adaptive way of working when projects require quick,
unexpected changes.
Self-organizing and self-sufficient ways of working that allow teams to
assign their own tasks and sprint goals and estimates.
Collaboration and independent management amongst team members to
improve delivery.
A common delusion about agile development is that everyone can do
everything. In fact, the opposite is true. To run a disciplined agile process,
well-defined roles and responsibilities are important.

© 2019 IBM Corporation

41
Agile Training Module

Although the names of these roles might differ from what you call them,
you'll likely find that their descriptions match roles that you're familiar with.
A key aspect of being agile is that people are empowered to make decisions
without many meetings and building consensus. This aspect can be a
significant challenge in some enterprise organizations. Project cadence
with playbacks to all interested parties is key to making the whole
organization more comfortable with decisions.

Core roles in an agile squad

In the most basic sense, a team is a group of people who work together to
accomplish a common goal. For a DevOps team, the goal is usually the
delivery of a product or a microservice that is part of a product. To achieve
success, make sure that the key roles are filled.

Product manager (product owner)

The role of the product manager is critical. The product manager ensures
that the team creates an engaging product and delivers business value by
meeting the needs of the markets. Product managers must understand
company strategy, market needs, the competitive landscape and which
customer needs are unfulfilled.

The product manager has these responsibilities:

• Owns the scope of the project, works with sponsor users, identifies
personas, defines the minimum viable product (MVP), and defines
hypotheses
• Collaborates with designers on the overall user experience, attends
playbacks with sponsor users and stakeholders, and collaborates through
user testing
• Defines, writes, and ranks the user stories that direct the design and
development work

© 2019 IBM Corporation

42
Agile Training Module

• Accepts user stories; that is, decides when a user story has delivered the
MVP
• Decides when to go to production and owns or collaborates on the "Go to
Market" plan

Larger projects might have more than one product manager. Ideally, the
project is divided into components or services that individual squads can
work on, and each squad has a product manager who provides direction.

The product managers must understand and coordinate requirements from

other components of an overall solution. Ultimately, one voice must direct
the design and development work of a squad.

Sponsor
The sponsor is typically an executive who has the vision and owns the
overall delivery and success of the project. Ideally, the squad has playbacks
and brings any issues to the sponsor each week. Part of the sponsor's job is
to ensure that the squad has everything it needs to succeed and to support
it in its use of agile methods.

User experience (UX) design lead

The UX design lead is responsible for all aspects of the project's user
experience. The goal of every project is to create experiences that delight
users. Reaching that goal requires a strong and experienced design leader
who can oversee all aspects of the design, from the initial workshop through
visual design and user testing.

The UX design lead has these responsibilities:

• Leads design thinking practices, such as persona definition, empathy

mapping, scenarios mapping, ideation, and MVP definition.

© 2019 IBM Corporation

43
Agile Training Module

• Creates great user experience concepts and produces wireframe sketches

to communicate the experience with the broader team.
• Drives collaboration with the extended design team, development team,
and product management team to maximize innovation.
• Collaborates with visual designers to deliver high-fidelity designs.
• Ensures a consistent user experience across all facets of an offering,
working with UX leaders in other squads when necessary.
• Plans and runs user testing to ensure that real-world feedback is injected in
all phases of the project. In some projects, a dedicated user researcher
assumes this responsibility.

Larger projects might have a UX designer or dedicated user researcher who

works with the UX design lead. In those cases, the UX design lead is
responsible for all aspects of the experience, but the UX designer might
create a few of the design artefacts.

Visual designer
The visual designer converts the user experience concepts into detailed
designs that emotionally connect with users.

The visual designer has these responsibilities:

• Uses his or her understanding of colour, fonts, and visual hierarchy to
convert conceptual designs into detailed designs that developers can build
• Creates all the necessary visual artefacts, including images, illustrations,
logos, and icons
• Ensures a consistent application of corporate styles and branding, or where
appropriate, suggests deviations from styles and branding

Sponsor user
A product that doesn't satisfy a real user need is a failed design. The best
way to ensure that your project meets users' needs is to involve users in the
process.

© 2019 IBM Corporation

44
Agile Training Module

A sponsor user is a real user—someone from outside your organization—

who will use the product that is being built. A sponsor user must be
carefully selected so that he or she accurately represents the needs of the
widest possible user base. In some cases, you might want more than one
sponsor user.
The sponsor user has these responsibilities:
• Represents the needs of the user throughout the process
• Participates in all phases of the project, from the initial design workshop
through design, development, and user testing
• Ensures that all decisions reflect the needs of the user

In some cases, the sponsor user might be the person who demonstrates
the design or prototypes to other stakeholders. What better way to show
the value of a design than to have a real user show it and explain why it
matters?

Developer
Developers build code by using core agile practices such as "keep it
simple," test-driven development (TDD), continuous integration, polyglot
programming, and microservice design. Agile development requires more
collaboration than is required in the waterfall model.

As part of a modern, agile DevOps team, developers must be adept at

rapidly learning and using new technologies. In a DevOps approach, the
developer role is merged with quality assurance (QA), release management,
and operations.

A developer has these responsibilities:

• Collaborates with the designers and product managers to ensure that the
code that is developed meets their vision
• Designs the solution to meet functional and non-functional requirements
• Writes automated tests, ideally before writing code

© 2019 IBM Corporation

45
Agile Training Module

• Writes code
• Develops delivery pipelines and automated deployment scripts
• Configures services, such as databases and monitoring
• Fixes problems from the development phase through the production phase,
which requires being on call for production support

For developers to have such broad roles, they rely on cloud technologies to
free them from many—and sometimes even all—infrastructure tasks. In an
ideal DevOps organization, the developers take on operations fully and are
on "pager duty" for production problems. In many companies, including
virtually all enterprises, an operations team provides the first response to
production issues.

However, you can still have a DevOps culture if the second call is to a
developer to fix the problem. For more information about the operations
roles that developers take on, see Cloud service management and
operations roles.

Teams might need developers with specialized skills, such as analytics or

mobile. In those cases, use pair programming to spread the skills
throughout the team.

In a DevOps approach the developer role is merged with quality

assurance (QA), release management, and operations.

Anchor developer (technical team lead)

An anchor developer is an experienced developer who provides leadership
on architecture and design choices, such as which UI framework to use on
a project. Even with the use of agile tracking tools, sponsors and

© 2019 IBM Corporation

46
Agile Training Module

stakeholders often want a direct report on progress, issues, and key

technical decisions. The anchor developer is that technical focal point who
also does development work.

Agile coach
The agile coach leads the organization in agile methods. The coach must
have the knowledge and experience to recommend changes to various
practices in response to unique circumstances within the organization. The
coach identifies problems and misapplications of the agile principles and
suggests corrections and continuous improvements.
One approach that works well is for the agile coach to be part of the squad
that has delivery responsibilities. In that way, the coach can provide
guidance about the method and practices as part of the day-to-day work.
The agile coach usually has experience with agile projects and is passionate
about the process and practices. Alternatively, an agile coach can work
across several squads and mentor them on the process and practices.

Depending on your squad structure and project size, the day-to-day

responsibilities of facilitating daily stand-up meetings, planning, and
playbacks might be the responsibility of either the agile coach or the anchor
developer.

Cloud Service Management and Operations roles

When you move to the cloud, the resulting culture change requires
modifications to the structure and roles of your project teams. Some
DevOps team members can play more than one role, and groups might be
merged to create a cohesive, diverse squad. As you form the Ops side of
your squad, consider the addition of several new roles.

Service management introduces processes that teams must implement to

manage the operational aspects of their applications. This diagram
illustrates the processes and the roles that are needed to implement them:

© 2019 IBM Corporation

47
Agile Training Module

Incident management roles

Incident management restores service as quickly as possible by using a
first-responder team that is equipped with automation and well-defined
runbooks. The incident management team members define the incident
process and build a tool chain that implements ChatOps across the
organization. Incident management roles include the first responder,
incident commander, subject matter expert, and site reliability engineer.
First responder
The first responder solves problems by using runbooks and working
with subject matter experts (SMEs). This role has these
responsibilities:
• Receives alerts through collaboration tools
• Researches to determine the nature of the problem

© 2019 IBM Corporation

48
Agile Training Module

• Evaluates and adjusts the urgency and priority of the problem, if

needed
• Contacts and communicates with the incident commander when a
major incident occurs
• Reviews known issues to determine whether the problem is a known
issue
• Tries to resolve the issue by using the prescribed runbooks,
collaborating with SMEs, or both
• Gains concurrence from the customer when the incident is resolved

Incident commander
The incident commander manages the investigation, communication,
and resolution of major incidents. This role has these responsibilities:

• Receives incident information and collaborates with SMEs to restore

services as fast as possible
• Updates key stakeholders with status and expected resolution times
• Seeks senior leadership support and endorsement, if needed
• Interfaces and works with vendors to isolate problems and drive
resolution
Keeping stakeholders up to date with the status of an incident is a key
responsibility of the incident manager.

Subject matter expert (SME)

SMEs apply the deep technical skills that are needed to resolve
application issues. Their skills support either specialized application
expertise or a specific technical field or domain, such as database
administration. An SME has these responsibilities:

• Investigates a problem by using monitoring tools to get more details

• Inspects logs
• Tests and verifies issues

© 2019 IBM Corporation

49
Agile Training Module

• Recommends fixes if instruction is missing for the first responder, or

fixes the problem
• Proposes changes if they're needed and requests change
management
• Implements change
• Provides data for the Site reliability engineer (SRE) review
SMEs use their skills to resolve problems as quickly as possible.

Site reliability engineer (SRE)

An SRE takes operational responsibility for supporting applications
and services that run on a global scale in the cloud by using a highly
automated service management approach. The SRE pays attention to
removing toil, which is repetitive manual labour that doesn't add real
value to a project.
An SRE spends approximately 50% of his or her working time on
engineering project improvements. Fundamentally, the role is a
combination of software engineering and operations design.

Problem management roles

Problem management aims to resolve the root cause of an incident to
minimize its adverse impact and prevent recurrence. The problem owner
and problem analyst ensure that problems are fixed and not repeated.

Problem owner
The problem owner oversees the handling of a problem and is
responsible to bring it to closure. As needed, this role enlists the help
of analysts and specialists. The problem owner is essentially the same
role as the traditional IT role. However, the tools that those roles use
to identify and solve a problem and ultimately provide a root cause
analysis are different. Typically, the problem owner has a strong
personal interest in the resolution.

© 2019 IBM Corporation

50
Agile Training Module

Problem analyst
The problem analyst discovers incident trends, identifies problems,
and determines the root cause of a problem. They're SMEs in one or
more areas. This role is radically different from the traditional IT
because business analytics, runbooks, and cognitive techniques play
a major role. However, human supervision and creative thinking are
still important in this role. Typically, an SRE takes this role.

Change management roles

The purpose of change management is to successfully introduce changes
to an IT system or environment. The roles that are associated with change
management are change owner, change manager, and change
implementer.

Change owner
The change owner is the person who requests the change. The change
owner has these responsibilities:

• Raises the change within the change management tool

• Creates the business case that justifies the change
• Sets the priority
• Determines the urgency

Input from the change owner is used to rank the change against all
the other work that the DevOps squad does.

Change manager
The change manager completes the preliminary assessment of a
change record to ensure that it contains the correct information. That
information includes an accurate description, correct classification,
and correct change type of standard, normal, or emergency.

© 2019 IBM Corporation

51
Agile Training Module

Before the change is implemented, the change manager verifies that

all the authorizations are obtained. After implementation, this role
reviews changes to ensure accuracy and quality.

Change implementer
This role implements changes. Typically, the change implementer is
an SRE or associated SME.

Other possible roles

Your project might need additional roles such as architect, project manager,
and user researcher.

Architect
In projects that have experienced developers and a strong anchor
developer, those roles provide "just-in-time" architecture. The use of
"just-in-time" architecture is typical for greenfield projects, which are
not imposed by pre-existing architecture. However, if enough
complexity exists, you need an architect who is separate from the
developers so that development work isn't impacted. You might need
an architect if a project is integrating to existing systems by using a
wide range of services, security, or movement of data, or if you're
coordinating with many other technical teams.

The architect works closely with the anchor developers across

squads. This role also works with other architects to ensure
architectural consistency across an offering portfolio. The architect
creates only the architectural designs, diagrams, and documents that
are actively used by the squads to guide their development. As in all
other roles, the focus must be on communication and collaboration
that is effective for the squads.

© 2019 IBM Corporation

52
Agile Training Module

Project manager
Tracking within the squads' day-to-day work is done through user
stories and tracking software, but often, dependencies exist on
groups outside the squad.
Project managers do a wide variety of tasks:

• Procure software
• Coordinate dependencies on systems, exposing APIs
• Report summaries beyond the tracking software
• Manage issues
• Coordinate integration with third parties

If the dependencies are minimal, the product manager, anchor

developer, or both might handle the project management tasks.
However, if those roles spend too much time on project management
tasks, a project manager is likely needed. Ideally, the project manager
has experience with agile teams and understands agile process and
tracking.

User researcher
The user researcher validates all the aspects of a design with real
users. Sometimes the UX leader fulfils this role. However, where more
extensive user research is part of the project, include a user research
expert as part of the team.
The user researcher has these responsibilities:
• Completes the initial research of users and their world to build
personas, empathy maps, and scenario maps
• Validates the problem statements and MVP with real users
• Plans and conducts usability tests throughout the project to get
real-world feedback on all ideas

© 2019 IBM Corporation

53
Agile Training Module

3.4 Agile vs Waterfall

Agile and Waterfall are very different software development methodologies

and are good in their respective way.

However, there are certain major differences highlighted below -

• Waterfall model is perfect for projects which have defined

requirements, and no changes are expected. On the other hand, Agile
is best suited where there is a higher chance of frequent requirement
changes.
• The waterfall is easy to manage, progressive and rigid method.
• Agile is very flexible and it possible to make changes in any phase.
• In Agile process, requirements can change frequently. However, in a
waterfall model, it is defined only once by the business analyst.
• In Agile Description of project, details can be altered anytime during
the SDLC process which is not possible in Waterfall method

Apart from these,

Agile Waterfall

It separates the project Software development process is divided

development lifecycle into sprints. into distinct phases.

It follows an incremental approach Waterfall methodology is a sequential

design process.

Agile methodology is known for its Waterfall is a structured software

flexibility. development methodology so most times
it can be quite rigid.

© 2019 IBM Corporation

54
Agile Training Module

Agile can be considered as a Software development will be completed

collection of many different projects. as one single project.

Agile is quite a flexible method There is no scope of changing the

which allows changes to be made in requirements once the project
the project development development starts.
requirements even if the initial
planning has been completed.

Agile methodology follows an All the project development phases like

iterative development approach designing, development, testing, etc. are
because of this planning, completed once in the Waterfall model.
development, prototyping and other
software development phases may
appear more than once.

Test plan is reviewed after each The test plan is rarely discussed during
sprint the test phase.

Agile development is a process in The method is ideal for projects which

which the requirements are have definite requirements and changes
expected to change and evolve. not at all expected.

In Agile methodology, testing is In this methodology, the "Testing" phase

performed concurrently with comes after the "Build" phase
software development.

© 2019 IBM Corporation

55
Agile Training Module

Agile introduces a product mindset This model shows a project mindset and
where the software product satisfies places its focus completely on
needs of its end customers and accomplishing the project.
changes itself as per the customer's
demands.

Agile methodology works Reduces risk in the firm fixed price

exceptionally well with Time & contracts by getting risk agreement at the
Materials or non-fixed funding. It beginning of the process.
may increase stress in fixed-price
scenarios.

Prefers small but dedicated teams Team coordination/synchronization is

with a high degree of coordination very limited.
and synchronization.

Products owner with team prepares Business analysis prepares requirements

requirements just about every day before the beginning of the project.
during a project.

Test team can take part in the It is difficult for the test to initiate any
requirements change without change in requirements.
problems.

Description of project details can be Detail description needs to implement

altered anytime during the SDLC waterfall software development
process. approach.

The Agile Team members are In the waterfall method, the process is
interchangeable, as a result, they always straightforward so, project

© 2019 IBM Corporation

56
Agile Training Module

work faster. There is also no need manager plays an essential role during
for project managers because the every stage of SDLC.
projects are managed by the entire
team

3.5 Agile Frameworks

Agile is an umbrella term for several iterative and incremental software
development approaches. The most popular Agile frameworks include
Scrum, Extreme programming, Kanban and Feature-Driven Development.
Several core Agile methodologies share the same philosophy expressed in
the Agile Manifesto. However, they have different practices, processes, and
techniques. While implementing Agile, it is not compulsory to follow an
Agile methodology. The best practices from different agile methodologies
can be chosen and implemented in the project.
Some of the key Agile methodologies are:

• Scrum
• Extreme Programming or XP
• Crystal
• Dynamic System Development Methodology or DSDM Atern
• Feature Driven Development or FDD
• Agile Project Management or APM
• Lean Kanban
• OpenUp

Let us discuss some of these Agile methodologies in detail in this lesson.

3.6.1 Extreme Programming (XP)

XP is a software development-centric Agile method and focuses on
implementing the best software practices. XP emphasizes the same
practices represented in the Agile Manifesto and reflected in Scrum. XP
introduced many revolutionary concepts to software development that are

© 2019 IBM Corporation

57
Agile Training Module

now standard practices, such as Test-Driven Development; Continuous

Integration; Iterations; and User Stories. The aim of these practices is to
ensure that customers receive what they need. XP allows developers to
respond to changing customer requirements at any point in the project
lifecycle.

3.6.1.1 History & Overview

Extreme Programming or XP was developed by Kent Beck and Ward
Cunningham in the 1990s in response to the high cost of changing
requirements and establish strong engineering practices to improve
software quality.

3.6.1.2 Activities
In Extreme Programming, the four basic activities are −
• Coding
• Testing
• Listening
• Designing
Coding
In pair programming, coding is considered the heart of development. You
code because if you do not code, at the end of the day you have not done
anything.
Testing
In pair programming, testing needs to be done to ensure that the coding is
done. If you do not test, you do not know when you have finished coding.
Listening
In pair programming, you listen to know what to code or what to test. If you
do not listen, you do not know what to code or what to test.

© 2019 IBM Corporation

58
Agile Training Module

Designing
In pair programming, you design so that you can keep coding and testing
and listening indefinitely, as good design allows extension of the system,
with changes in only one place.
These activities are performed during −
• Release Planning
• Iteration Planning
• Implementation

3.6.1.3 Values & Principles

Extreme programming builds around five core principles.

1. Communication: This principle focuses on ensuring that everyone in

the team knows what needs to be done and what the other person is
doing. There will be a frequent collaboration between users and
programmers. The team members communicate using simple
designs, common metaphors, and application of patterns.
2. Simplicity: The focus of this principle is to find the simplest solution
instead of complicating the solution with unwanted features and
functionalities. The team will take small simple steps towards the
goal and mitigate complexities and failures, by refactoring.
3. Feedback: This principle focuses on ensuring that the solution is
demonstrated to the stakeholders early and regularly. Unit tests are
conducted for feedback from the system; Acceptance Tests are
conducted for feedback from the customer, and Planning Games are
conducted for feedback from the team.
4. Courage: This principle focuses on the courage required to showcase
the work being done. The team should allocate enough time within
the sprint to refactor the code. Refactoring makes future changes

© 2019 IBM Corporation

59
Agile Training Module

easier and removes obsolete code. The team should showcase the
partially done work during Pair Programming.
5. Respect: This principle focuses on giving and taking. This includes
respect for others; self-respect; adopting the other four values, and
respect gained from others in the team.

3.6.1.4 Practices & Roles

The XP Practices introduced a wide range of techniques that are accepted
as standard practices.
Some of the techniques are:
• Fine-scale feedback, which includes: Pair programming;
Planning game; Test-driven development; and Whole team;
• Continuous process, which includes: Continuous integration;
Refactoring or design improvement; and Small releases;
• Shared understanding, which includes: Coding standards;
Collective code ownership; Simple design; and System
metaphor;
• Programmer welfare, which includes Sustainable pace.

3.6.1.5 Rules for Planning, Managing, Design, Coding, and Testing

The following rules are explained in the website of Extreme
programming:

Planning
• User stories are written.
• Release planning creates the release schedule.
• Make frequent small releases.
• The project is divided into iterations.
• Iteration planning starts each iteration.

Managing

• Give the team a dedicated open work space.

© 2019 IBM Corporation

60
Agile Training Module

• Set a sustainable pace.

• A stand up meeting starts each day.
• The Project Velocity is measured.
• Move people around.
• Fix XP when it breaks.

Coding
• The customer is always available.
• Code must be written to agreed standards.
• Code the unit test first.
• All production code is pair programmed.
• Only one pair integrates code at a time.
• Integrate often.
• Set up a dedicated integration computer.
• Use collective ownership.

Designing
• Simplicity.
• Choose a system metaphor.
• Use CRC cards for design sessions.
• Create spike solutions to reduce risk.
• No functionality is added early.
• Refactor whenever and wherever possible.

Testing
• All code must have unit tests.
• All code must pass all unit tests before it can be released.
• When a bug is found tests are created.
• Acceptance tests are run often and the score is published.

© 2019 IBM Corporation

61
Agile Training Module

3.6.1.6 Extreme Programming Diagram

In the given XP process diagram, you can see the normal flow of an XP
project. Architectural spike and user stories are taken as input for the
release planning. The outcome of this meeting would result in the release
plan, which would drive the iterations planned within the release.

The outcome of each iteration would be compared against the acceptance

criteria and upon customer approval, the code would be shipped to the live
environment through small release. This cycle of release planning, iteration
planning, development, testing, and customer acceptance repeats for the
entire duration of the project.

3.6.2 Rational Unified Process (RUP)

RUP is a risk-driven, use-case-based, and architecture-centric, iterative

software development process. RUP embodies industry-standard
management and technical methods and techniques to provide a software
engineering process particularly suited to creating and maintaining
component-based software system solutions. RUP communicates roles,
activities, and artefacts organized by process workflows that guide project
teams through software engineering disciplines under the purview of
operational business phases and decision-making milestones.

© 2019 IBM Corporation

62
Agile Training Module

RUP's foundation consists of three key elements: the role, the activity, and
the artefact.

The role performs activities and produces artefacts. Each role is primarily
responsible for a set of activities and artefacts. But all roles will contribute
to other activities and artefacts. Roles, activities, and artefacts are used
repeatedly during the execution of workflows. The workflows form a
sequence of tasks unique to each of the nine software disciplines in the RUP
iterative development software lifecycle framework

Process Overview
The RUP framework is two dimensional, with axes indicating time and
content. The time dimension is ordered by phases, iterations, and
milestones. The content dimension consists of software disciplines
containing the workflows, roles, activities, and artefacts as they apply to
that discipline.

© 2019 IBM Corporation

63
Agile Training Module

Phases and Iterations – The Time Dimension

This is the dynamic organization of the process along time.
The software lifecycle is divided into cycles with each cycle working on a
new generation of the product. The Rational Unified Process divides one
development cycle in four consecutive phases
• Inception phase
• Elaboration phase
• Construction phase
• Transition phase
Each phase is concluded with a well-defined milestone—a point in time at
which certain critical decisions must be made, and therefore key goals
must have been achieved
Static structure of the process
A process describes who is doing what, how, and when. The Rational
Unified Process is represented using four primary modelling elements:
• Workers, the ‘who’
• Activities, the ‘how’
• Artefacts, the ‘what’
• Workflows, the ‘when’
Core Workflows
There are nine core process workflows in the Rational Unified Process,
which represent a division of all workers and activities into logical
groupings.
The core process workflows are divided into six core “engineering”
workflows:

© 2019 IBM Corporation

64
Agile Training Module

1. Business modelling workflow

2. Requirements workflow
3. Analysis & Design workflow
4. Implementation workflow
5. Test workflow
6. Deployment workflow
And three core “supporting” workflows:
1. Project Management workflow
2. Configuration and Change Management workflow
3. Environment workflow
Although the names of the six core engineering workflows may evoke the
sequential phases in a traditional waterfall process, we should keep in mind
that the phases of an iterative process are different and that these
workflows are revisited again and again throughout the lifecycle. The actual
complete workflow of a project interleaves these nine cores workflows and
repeats them with various emphasis and intensity at each iteration.

3.6.3 Feature Drive Development (FDD)

3.6.3.1 Overview
Feature Driven Development (FDD) is an agile framework that, as its name
suggests, organizes software development around making progress on
features. Features in the FDD context, though, are not necessarily product
features in the commonly understood sense.
3.6.3.2 Advantages and Disadvantages
Advantages
• Simple five-step process allows for more rapid development

© 2019 IBM Corporation

65
Agile Training Module

• Allows larger teams to move products forward with continuous

success
• Leverages pre-defined development standards, so teams can move
quickly
Disadvantages
• Does not work efficiently for smaller projects
• Less written documentation, which can lead to confusion
• Highly dependent on lead developers or programmers

3.6.3.3 Life cycle

FDD was designed to follow a five-step development process, built largely
around discrete “feature” projects.
Project lifecycle looks like this:

1. Develop an overall model

Client and the development team make an overall model. Detailed
domain models are created and then these models are progressively
merged into overall model. Guided by a chief architect, team members
get a good understanding of the complete model.

2. Build a features list

Information gathered in previous step is now deduced to make a list of
required features. A feature is a small, client valued output. The whole
project is thereby divided into features. A feature needs to be delivered
every two weeks. Therefore, any feature the team decides to work on
must take less than two weeks to be implemented.

© 2019 IBM Corporation

66
Agile Training Module

3. Plan by feature
Once the development of features is planned, it’s all about in which order
the features will be implemented. Teams are selected and assigned with
feature sets.

4. Design by feature
Chief programmer chooses the features and the domain classes that will
be involved in designing the feature. Sequence diagrams are drawn, and
general designs of the features are also finalised. Class and method
prologues are written. This is all followed by a design inspection.

5. Build by feature
After the design inspection, the domain expert explains the specifics.
Class owners start building and implementing all the items necessary to
support the design. Code is developed, unit tested, inspected and
approved by Chief Programmer who then approves it and then the
completed feature is added to the main build.

3.6.4 Test Driven Development (TDD)

Test-driven development (TDD), which is rooted in extreme programming,
is all about satisfying your team that the code works as expected for a
behaviour or use case. Instead of aiming for the optimum solution in the
first pass, the code and tests are iteratively built together one-use case at
a time. Development teams use TDD as part of many coding disciplines to
ensure test coverage, improve code quality, set the groundwork for
their delivery pipeline, and support continuous delivery.
3.6.4.1 Overview
The basic concept of TDD is that all production code is written in response
to a test case. Robert C. Martin, who is known as Uncle Bob, describes
these Three Laws of TDD:

© 2019 IBM Corporation

67
Agile Training Module

• You are not allowed to write any production code unless it is to make
a failing unit test pass.
• You are not allowed to write any more of a unit test than is enough to
fail; and compilation failures are failures.
• You are not allowed to write any more production code than is enough
to pass the one failing unit test.

3.6.4.2 Benefits
TDD provides several benefits:

• It can enable faster innovation and continuous delivery because the code
is robust.

• It makes your code flexible and extensible. The code can be refactored or
moved with minimal risk of breaking code.

• The tests themselves were tested. A key characteristic of a test is that it

can fail, and the development team verifies that each new test fails.

• The code that is produced is, by design, easy to test.

• The requirements are implemented with little to no wasted effort because

only the function that is needed is written.

3.6.4.3 Life cycle

A TDD cycle incorporates Uncle Bob's three TDD rules and adds a
refactoring step after the tests pass:

© 2019 IBM Corporation

68
Agile Training Module

TDD practitioners refer to this cycle as the Red/Green/Refactor cycle. In the

article TDD - What it is and what it is not, Andrea Koutifaris describes this
cycle:

• Red phase: You write an automated test for a behaviour that you're about to
implement. Based on the user requirement, you decide how you can write
a test that uses a piece of code as if it were implemented. This is a good
opportunity to think about the externals of the code, without getting
distracted by filling in the implementation. Think about what the interface

© 2019 IBM Corporation

69
Agile Training Module

should look like? What behaviours should a caller of that interface expect?
Is the interface clean and consumable?

• Green phase: You write production code, but only enough production code
to pass the test. You don't write algorithms, and you don't think about
performance. You can duplicate code and even violate best practices. By
addressing the simplest tasks, your code is less prone to errors and you
avoid winding up with a mix of code: some tested (your minimalist
functions) and some untested (other parts that are needed later).

• Refactor phase: You change the code so that it becomes better. At a

minimum, you remove code duplication. Removing duplication generally
leads to abstraction. Your specific code become more general. The unit
tests provide a safety net which supports the refactoring, because they
make sure that the behaviour stays the same and nothing breaks. In
general, tests should not need to be changed during the refactor stage.

3.6.4.4 Types of Tests

If your team is hesitant to skip traditional unit tests, remember: TDD
drives the code development, and every line of code has an associated
test case, so unit testing is integrated into the practice. Unit testing is
repeatedly done on the code until each unit functions per the
requirements, eliminating the need for you to write more unit test cases.

At IBM, teams found that the built-in unit testing produces better code.
One team recently worked on a project where a small portion of the team
used TDD while the rest wrote unit tests after the code. When the code
was complete, the developers that wrote unit tests were surprised to see
that the TDD coders were done and had more solid code.

Unlike unit testing that focuses only on testing the functions, classes, and
procedures, TDD drives the complete development of the application.
Therefore, you can also write functional and acceptance tests first.

© 2019 IBM Corporation

70
Agile Training Module

To gain the full benefits of unit testing and TDD, automate the tests by
using automated unit test tools. Automating your tests is essential for
continuous integration and is the first step in creating an automated
continuous delivery pipeline.

3.6.5 Scrum
By now, you’ve most probably known about the term – “Scrum”. It is a
popular agile project management methodology which focuses on defining
key features and its objectives in the beginning of each sprint.
Simply put, Scrum was introduced to reduce the overall risk in a software
project, while also providing the value faster.

3.6.5.1 Definition and History of Scrum

Scrum methodology is one of the leading Agile techniques developed in
the 1990s by Ken Schwaber and Jeff Sutherland. It is a term used in Rugby
game and refers to an interlocked team working together to push a rugby
ball into the hands of their team members, so they can move it down the
field and score.
In the context of software development, Scrum is a method of project
management in an agile development process to keep the focus on
delivering the highest business value to stakeholders in the shortest
possible time.
The Scrum process helps ensure that the most valuable remaining
features are built next, and it emphasizes that work always be completed
to the point of being deliverable. Work is structured in two-to-four-week
sprints, or iterations, with working software produced by the end of each
sprint.

© 2019 IBM Corporation

71
Agile Training Module

3.6.5.2 Overview of Scrum

Scrum is an iterative and incremental approach to software development,
meaning that a large project is split into a series of iterations called
“Sprints”, where in each sprint, the goal is to complete a set of tasks to
move the project closer to completion.
Each sprint typically lasts 2 to 4 weeks or a calendar month at most.
Building products one small piece at a time encourages creativity and
enables teams to respond to feedback and change and to build exactly
what is needed.
In scrum, product is designed, coded and tested in the sprint.
A key principle of Scrum is its recognition that: during a project the
customers can change their minds about what they want or need, and that
unpredicted challenges cannot be easily addressed in a traditional
predictive or planned manner. As such, Scrum adopts an empirical
approach—accepting that the problem cannot be fully understood or
defined, focusing instead on maximizing the team’s ability to deliver
quickly and respond to emerging requirements.

3.6.6 Kanban
Many development teams use the Kanban method to manage their work.
Fundamentally, Kanban is a visual representation of work in progress. A
Kanban board can be as simple as sticky notes and lanes on a whiteboard
or your team may adopt web-based tools that can be accessed by everyone
on your team. On-line Kanban boards are especially useful if your team is
not co-located.

© 2019 IBM Corporation

72
Agile Training Module

3.6.6.1 History & Overview

Kanban has two important principles: the workflow is visible to the entire
team and the work in progress is limited to the capacity of the people who
are doing the work. You can't keep adding work to the queue and expect it
to get done—or done well.

By following the Kanban method, teams can deliver features quickly,

reduce the inefficiencies of multitasking, and identify bottlenecks and
dependencies.

The basic Kanban workflow is as follows:

• New: Work that is new to the team and has not yet been added to the
backlog.
• Ranked backlog: Work that is waiting to be started, ranked in order of
importance and size.
• Work in progress: Work that is in progress by a team member.
• Under review: Another member of the team checks the work.
• Done: If review goes well, the work is complete and ready for
production.
• Repeat: A team member takes the next item from the backlog.

3.6.6.2 Kanban board

The format of your Kanban board might change depending on the group
you're working with. For example, a management team might use a board

© 2019 IBM Corporation

73
Agile Training Module

to track epic stories or broad ideas. A development team might use its board
to track the backlog and work that is in progress and completed.

Types of Kanban boards:

Three types of Kanban walls and headers are common:

• Portfolio walls: For management-level tracking of whole projects or epics

across a larger organization
▪ Headers: Idea, In Discovery, In Delivery
• Program walls: For project-management-level tracking of a project across
several teams
▪ Headers: Backlog, In-progress, under review, Done
• Team walls: For team-level tracking of work
▪ Headers: Backlog, In-progress, under review, Done

Agile Certifications:
Here are the top 5 Agile certifications which are the best for Agile
professionals who want to build their career with Agile methodology.

1. PMI-ACP (Agile Certified Professional)

2. Scrum Alliance (Certified Scrum Master/Certified Scrum Product
Owner/Certified Scrum Developer)
3. Scrum Alliance (Certified Scrum Professional)
4. Scrum.org (Professional Scrum Master/Professional Scrum
Product Owner/Professional Scrum Developer -1)
5. SAFe Scaled Agilists

© 2019 IBM Corporation

74
Agile Training Module

Exercise 1:
Introduction: This is an exercise that we came up with to better
communicate the twelve principles behind the Agile Manifesto.

Procedure:
• Divide participants in to groups, each with a white-board or flip-chart
and markers.
• Have the teams write down the numbers 1 through 12.
• Challenge each team to, within a 15-minute time-box, come up
with three words maximum that effectively capture each of the twelve
principles.
• To avoid ‘analysis paralysis’, make sure to give the teams time updates
throughout (e.g. 10, 5, 2, 1-minute warnings). You will find that teams
will speed up towards the end.
• When time is up, go through each principle and discuss which are the
most important words. Sometimes I like to ask people what their most
and least favourite principles are.
• Post the condensed principles somewhere visible, to make it a regular
talking point.

Logistics:
• Copies of the twelve principles of agile software
• White-boards and/or flip-charts
• Markers

© 2019 IBM Corporation

75
Agile Training Module

Test Your Knowledge

1. All the following are Agile Manifesto Values except?

a. Working Software Over Comprehensive Documentation
b. Customer Collaboration Over Contract Negotiation
c. Gated Delivery Over Iterative Development
d. Individuals and Interactions Over Processes and Tools

2. Agile Software Development is:

a. A methodology to iteratively develop products
b. Defined in the Agile Manifesto for Software Development
c. Based on the Scrum Papers
d. All the above

3. Typically, in Agile Development, large Projects/Products are

decomposed in what order?
a. Feature, Epic, Story
b. Epic, Feature, Story
c. Story, Feature, Epic
d. There is no specific order

4. Test Driven Development (TDD) involves creating tests and code

almost simultaneously, while constantly improving the design. Many
Agile developers believe TDD helps ensure correct implementation
while reducing the cost of change. Is TDD part of Scrum?
a. Yes - Scrum is a complete methodology containing everything
you need to succeed
b. No - Scrum is only a feedback framework. It does not specify
technical practices

© 2019 IBM Corporation

76
Agile Training Module

5. In an organization that embraces Agile values, who would be

responsible for tool selection and configuration?
a. The teams, who would have to coordinate with each other
b. The Scrum Masters, who would have to coordinate with each
other

© 2019 IBM Corporation

77
Agile Training Module

Chapter 4: Scrum – Deep Dive

Scrum is an agile development methodology for managing and completing
projects. It is a way for teams to work together to achieve a set of common
goals.

Scrum is the most popular Agile methodology and more than 50% of the
projects make use of this methodology. Some of the salient features that
make Scrum methodology popular are as follows:

• Scrum offers simplicity and proven results

• It incorporates other Agile engineering techniques
• It stresses small teams and team empowerment
• It accepts changes to requirements
• It allows working from a single source of prioritized work items
• Scrum includes daily status meetings
• It offers team commitment to a potentially shippable increment
during a ‘Sprint’

4.1 Foundations of Scrum

The three pillars of Scrum methodology are Transparency, Inspection, and
Adaptation.
Transparency:
• All aspects of the process or project must be visible to those
responsible for the outcome.
• Use Information radiators, through which key information like product
backlog, sprint backlog, impediments, risks, and project progress are
made transparent to all the stakeholders.

© 2019 IBM Corporation

78
Agile Training Module

Inspection:

• The team regularly inspects their performance and progress towards

the project goal.
• They constantly look for problematic areas and deviations from the
plan.

Adaptation:

• Based on the observations made during an inspection, essential

changes are made to the process to avoid problem relapse and
improve the project delivery position.

4.2 Scrum Diagram

Below is the diagram that’s most commonly used to show the scrum
process flow.

© 2019 IBM Corporation

79
Agile Training Module

4.3 Scrum Team

A Scrum Team is a group of individuals working together to deliver the
requested and committed product increments. To work effectively it is
important for a Scrum Team that everyone within the team follows a
common goal.
Within the Scrum Framework all work delivered to the customer is done by
dedicated Scrum Teams. A Scrum Team is a collection of individuals
working together to deliver the requested and committed product
increments.

To work effectively it is important for a Scrum Team that everyone within

the team

• follows a common goal

• adheres the same norms and rules
• shows respect to each other

When setting up a new Scrum Team one always must keep in mind that no
new team will deliver with the highest possible performance right from the
beginning. After setting up the team it must go through certain phases as
described by the Tuckman-Model: Forming, Storming, Norming,
performing.

How long it takes until the Scrum Team is in the Performing Phase depends
on the team, and yet it normally takes about 3 Sprints until the teams is
mature enough to deliver their results in a predictable way.

© 2019 IBM Corporation

80
Agile Training Module

Characteristics of a Scrum Team

Scrum Teams always have the following characteristics:

• Team members share the same norms and rules

• The Scrum team is held responsible for the delivery
• The Scrum Team is empowered
• It is working as autonomous as it is possible
• The Scrum Team is self-organizing
• The skills within the Scrum team are balanced
• A Scrum Team is small and has no sub-teams
• The people within the Scrum Team work full time in the team
• People are collocated

4.4 Roles in Scrum Team

Within the Scrum Framework three roles are defined:
• The Scrum Team
• Scrum Master

© 2019 IBM Corporation

81
Agile Training Module

• Scrum Product Owner

Each of these roles has a well-defined set of responsibilities and only if they
fulfil these responsibilities, closely interact and work together they can
complete a project successfully.

The Product Owner is responsible for maintaining this list and revising
priorities for items as the project progresses and the business environment
changes. The Product Owner is responsible for the success of the product.
He or she defines the features and release schedule and is responsible for

© 2019 IBM Corporation

82
Agile Training Module

determining the business value of the various features. The Product Owner
constantly refines and reprioritizes the Product Backlog.

The ScrumMaster manages the Scrum process, ensuring that the Scrum
practices are properly executed and that Scrum values are understood by
the team members. He or she ensures that the team is fully productive by
eliminating impediments and shielding them from outside interference (at
least during a sprint).
A Scrum team should be a cross-functional mix of the right skills to
complete the project (for example: developers, testers, interaction
designers, writers). Team members should be committed to the Scrum
team full-time.

4.5 Sprints
A sprint is a short, time-boxed period when a scrum team works to
complete a set amount of work. Sprints are at the very heart
of scrum and agile methodologies, and getting sprints right will help
your agile team ship better software with fewer headaches

4.6 Definition of Ready

Definition of ready is a working agreement between the team and product
owner on what readiness means. It is an input criterion to plan a story in a
sprint. It is a way for a product owner to indicate an item in the product
backlog as ready to work in sprint. It is the accountability of product owner
that there is a definition of ready defined. Scrum team can refuse to take an
item into sprint. The team makes explicit and visible the that a user story
must meet prior to being accepted into the upcoming iteration.

© 2019 IBM Corporation

83
Agile Training Module

Test Your Knowledge

1. Does scrum have a role called “project manager”?
a. No
b. Yes

2. Who owns sprint commitments?

a. Individuals, as assigned by ScrumMaster
b. The team owns them collectively
c. The ScrumMaster
d. Individuals, as determined during the Sprint planning meeting

3. When should a retrospective meeting be held?

a. Only at the end of a release
b. At the end of each sprint, before the sprint review meeting
c. At the end of each sprint, after the sprint review meeting
d. Every now and then, when the team wants to improve
e. Only at the end of a project

4. Does scrum have rules, or just guidelines?

a. Scrum has a few simple rule
b. Scrum has guidelines only, no rules at all.

5. Who is responsible to measure the Project’s performance?

a. The Scrum Master
b. The Delivery Manager
c. The Product Owner
d. The Development Team
e. The Scrum Team

© 2019 IBM Corporation

84
Agile Training Module

Chapter 5: Scrum Artifacts

Scrum Artefacts provide key information that the Scrum Team and the
stakeholders need to be aware of;
- for understanding the product under development
- the activities being planned
- and the activities done in the project.
The following artefacts are defined in Scrum Process Framework.
These are the most common artefacts in a scrum project and project
artefacts are not limited by these.
• Product Backlog
• Sprint Backlog
• Burndown Chart
• Product Increment
• Impediments List
• Product Vision
• Sprint Goal
• Definition of Done

Let's touch upon some of the most commonly used artefacts.

Product Backlog
The product owner defines the features and release schedule and is
responsible for determining the business value of the various features. The
product owner constantly refines and reprioritizes the Product Backlog.

© 2019 IBM Corporation

85
Agile Training Module

Requirements are documented as items in the Product Backlog. This is one

of the most important artefacts in a scrum project. It is a prioritized list of
all desired work or features for the project. The product owner is
responsible for maintaining this list and revising priorities for items as the
project progresses and the business environment changes. Ideally, the
items in the Product Backlog are stated in terms that indicate their business
values to the stakeholders.

Sprint Backlog
The Scrum team and Scrum Master hold a Sprint Planning meeting at the
start of each sprint. At this meeting, the product owner presents the
features from the Product Backlog that are most desired for the upcoming
sprint, describing them so that the team can grasp what is expected. The
product owner and team agree on a goal for the sprint. This is essentially a
vision statement focused on the work for the next two to four weeks. The
team then determines how to accomplish the sprint goal and breaks the
features down into the tasks required.

© 2019 IBM Corporation

86
Agile Training Module

This list of tasks becomes the Sprint Backlog. The items in the backlog have
time estimates so that the team can determine whether the items can be
completed within one sprint. If there is insufficient time, a feature can be
taken off the Sprint Backlog list and returned to the Product Backlog.
Estimation is done as a team exercise and is not determined by the scrum
master or product owner. The Sprint Backlog represents the work that the
team has committed to finish during the sprint.

During the Daily Scrum meeting, each team member answers three
questions:

• What did I do yesterday?

• What will I do today?
• What is blocking my progress (if anything)?

This is not a status meeting, but a planning and commitment meeting. The
whole thing should take less than 15 minutes. This regular communication
about what everyone is doing and what issues they are facing can eliminate
the need for other meetings and help team members work more effectively
together.

© 2019 IBM Corporation

87
Agile Training Module

At the end of each sprint, the team shows off the work that it has
accomplished during the Sprint Review meeting. This is a brief and informal
meeting to which all concerned parties are invited. Its purpose is to
demonstrate the working software and to get feedback from participants
and stakeholders on the results.

After the Sprint Review, the team meets by itself to hold the Sprint
Retrospective. During this meeting, they talk about what is going well — and
what isn't — with respect to the project and their process. This meeting
should result in some change in how they work for the coming sprints,
because they work to continually improve their team and practice
effectiveness.

Sprint Burndown chart

As items from the Product Backlog are selected for completion during the
sprint planning meeting, they become part of a Sprint Backlog. As
mentioned previously, the Sprint Backlog contains specific tasks associated
with the features from the Product Backlog. During the sprint, the status of
the work items in the Sprint Backlog is updated daily. The updated status
makes it possible to generate a Sprint Burndown chart. This chart is a
graphical display of the amount of work remaining in the project. It is also
common for it to include an "ideal" line that indicates a smooth progression
of the work from start to finish of the sprint. The ideal line indicates how
work would progress if even proportions of it are completed each day of the
sprint.

© 2019 IBM Corporation

88
Agile Training Module

Although the actual work progress will likely not follow this line, significant
deviations are a cause for concern, particularly if the actual progress
continues to trend away from the ideal.

Impediments List
When there are impediments or blocks to progress, the scrum master might
maintain an Impediments List as an additional scrum artefact.

Product Increment
Product Increment is one of the important artefacts of Scrum. Product
Increment is the combination of all the completed list of Product Backlog
items during the sprint. Product Increment keeps getting incremented in
the subsequent sprints. So, in a sprint, the Product increment is the
integration of all the completed list of Product Backlog Items. Where as in
a Project, Product Increment is the integration of all the completed list of
Sprint backlog items. With each sprint, the product increment increases in
terms of delivered functionality.

© 2019 IBM Corporation

89
Agile Training Module

Test Your Knowledge

1. When is the sprint backlog created?

a. Whenever needed
b. During the backlog refinement meeting
c. During the sprint planning meeting
d. At the beginning of the project

2. Should the product backlog contain tasks?

a. No
b. Yes

3. What does a Burn-Down Chart display?

a. Project Progress
b. Amount of remaining work with respect to time
c. The velocity of the team
d. The capacity of the team members
e. How many more items can be picked up in a Sprint

4. List maintained by the Scrum master to note the blocks to the project
progress is called _______________.
a. Product Backlog
b. Burn-down chart
c. Product vision
d. Impediment list

© 2019 IBM Corporation

90
Agile Training Module

Chapter 6: Scrum Ceremonies

6.1.1: Sprint Planning

Definition: Sprint planning is an event where the team determines the

product backlog items they will work on during that sprint and discusses
their initial plan for completing those product backlog items in the Scrum
framework.

This plan is created by the collaborative work of the entire Scrum Team.

When should you do sprint planning

Each sprint begins with a sprint planning meeting. For a one month or
four-week sprint this meeting should last eight hours. For a two-week
sprint, plan for about four hours. As a rule of thumb, multiply the number
of weeks in your sprint by two hours to get your total sprint planning
meeting length.

Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming

Sprint?
• How will the work needed to deliver the Increment be achieved?

Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be

developed during the Sprint. The Product Owner discusses the objective
that the Sprint should achieve and the Product Backlog items that, if
completed in the Sprint, would achieve the Sprint Goal. The entire Scrum
Team collaborates on understanding the work of the Sprint.

© 2019 IBM Corporation

91
Agile Training Module

The input to this meeting is the Product Backlog, the latest product
Increment, projected capacity of the Development Team during the Sprint,
and past performance of the Development Team. The number of items
selected from the Product Backlog for the Sprint is solely up to the
Development Team. Only the Development Team can assess what it can
accomplish over the upcoming Sprint. During Sprint Planning the Scrum
Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be
met within the Sprint through the implementation of the Product Backlog,
and it provides guidance to the Development Team on why it is building
the Increment.

Topic Two: How will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the
Sprint, the Development Team decides how it will build this functionality
into a “Done” product Increment during the Sprint. The Product Backlog
items selected for this Sprint plus the plan for delivering them is called the
Sprint Backlog.

The Development Team usually starts by designing the system and the
work needed to convert the Product Backlog into a working product
Increment. Work may be of varying size, or estimated effort. However,
enough work is planned during Sprint Planning for the Development Team
to forecast what it believes it can do in the upcoming Sprint. Work planned
for the first days of the Sprint by the Development Team is decomposed
by the end of this meeting, often to units of one day or less. The
Development Team self-organizes to undertake the work in the Sprint
Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items
and make trade-offs. If the Development Team determines it has too
much or too little work, it may renegotiate the selected Product Backlog
items with the Product Owner. The Development Team may also invite
other people to attend to provide technical or domain advice.

© 2019 IBM Corporation

92
Agile Training Module

By the end of the Sprint Planning, the Development Team should be able
to explain to the Product Owner and Scrum Master how it intends to work
as a self-organizing team to accomplish the Sprint Goal and create the
anticipated Increment.

Why is Sprint planning important?

Sprint Planning is important because we can define the Sprint Goal which
is the outcomes of it and a plan of delivering the Increment. Additionally,
the Sprint Backlog contains all the work that should be done in details,
which allows the Development Team to forecast the time and work
needed.

What should happen during sprint planning?

The Sprint Goal is an objective set for the Sprint that can be met through
the implementation of Product Backlog. It provides guidance to the
Development Team on why it is building the Increment. It is created
during the Sprint Planning meeting.

The Planning Steps

1. Remind the team of the big picture or goal

2. Discuss any new information that may impact the plan
3. Present the velocity to be used for this release
4. Confirm team capacity
5. Confirm any currently known issues and concerns and record as
appropriate
6. Review the definition of DONE and make any appropriate updates
based on technology, skill, or team member changes since the last
sprint
7. Present proposed product backlog items to consider for the sprint
backlog

© 2019 IBM Corporation

93
Agile Training Module

8. Determine the needs, sign up for work, and estimate the work
owned
9. Product Owner answers clarifying questions and elaborates
acceptance criteria
10. Confirm any new issues and concerns raised during meeting
and record.
11. Confirm any assumptions or dependencies discovered during
planning and record.
12. ScrumMaster calls for a group consensus on the plan.
13. Team and Product Owner signal if this is the best plan they can
make given what they know right now.
14. Get back to work.

Sprint Planning Template

© 2019 IBM Corporation

94
Agile Training Module

6.1.2: Daily Scrum Meeting

In Scrum, on each day of a sprint, the team holds a daily scrum meeting
called the "daily scrum.” Meetings are typically held in the same location
and at the same time each day. Ideally, a daily scrum meeting is held in
the morning, as it helps set the context for the coming day's work. These
scrum meetings are strictly time-boxed to 15 minutes. This keeps the
discussion brisk but relevant.

The daily scrum meeting is not used as a problem-solving or issue

resolution meeting. Issues that are raised are taken offline and usually
dealt with by the relevant subgroup immediately after the meeting. During
the daily scrum, each team member answers the following three
questions:

1. What did you do yesterday?

2. What will you do today?
3. Are there any impediments in your way?

By focusing on what each person accomplished yesterday and will

accomplish today, the team gains an excellent understanding of what
work has been done and what work remains. The daily scrum meeting is
not a status update meeting in which a boss is collecting information
about who is behind schedule. Rather, it is a meeting in which team
members make commitments to each other.

If a programmer stands up and says, "Today, I will finish the data storage
module," everyone knows that in tomorrow's meeting, he will say whether
he finished. This has the wonderful effect of helping a team realize the
significance of these commitments, and that their commitments are to one
another, not to some far-off customer or salesman.

© 2019 IBM Corporation

95
Agile Training Module

Any impediments that are raised in the scrum meeting become the
ScrumMaster's responsibility to resolve as quickly as possible.

Typical impediments are:

• My ____ broke and I need a new one today.

• I still haven't got the software I ordered a month ago.
• I need help debugging a problem with ______.
• I'm struggling to learn ______ and would like to pair with someone
on it.
• I can't get the vendor's tech support group to call me back.
• Our new contractor can't start because no one is here to sign her
contract.
• I can't get the ____ group to give me any time and I need to meet
with them.
• The department VP has asked me to work on something else "for a
day or two."

In cases where the ScrumMaster cannot remove these impediments

directly himself (e.g., usually the more technical issues), he still takes
responsibility for making sure someone on the team does quickly resolve
the issue.

Most teams conduct the daily scrum meeting by having each person
answer the three questions in order. You answer all three, then the next
person, the next and so on. An interesting alternative that some teams find
helpful is to talk through one product backlog item before moving on to
the next. In this way, an individual may give an update at multiple different
times during the same meeting.

Daily scrum meeting Preparation

1. The Scrum teams of size 10 or less are most effective. ...

2. Logistics. Schedule a time and a place for daily scrum. ...
3. Use cues. ...

© 2019 IBM Corporation

96
Agile Training Module

4. Remain standing. ...

5. Use the 3-question agenda. ...
6. Don't delay the start of the meeting. ...
7. Don't use scrum meeting as a planning meeting. ...
8. Don't allow the meeting to go off track.

Purpose of daily scrum:

The purpose of the Daily Scrum is to inspect and synchronize the team's
progress towards the Sprint Goal for next 24hrs, discuss if anything
impedes the team and re-plan the team's work to achieve the Sprint Goal.
It is not a traditional status meeting.

Importance of Daily Scrum Meeting:

During the daily scrums, the team gets an excellent understanding about
each other's accomplishments and plan for future. The scrum master is
responsible for resolving any impediments that are raised in the meeting.
If he can't, at least he ensures someone else does.

Daily Stand-up Characteristics

• Meeting takes place in the morning for 15 minutes

• Participants include all the scrum team members, especially the
scrum master and product owner
• The scrum meeting is usually not extended beyond 15 minutes with
all the people standing up
• Scrum affords special status for the scrum master or those who are
committed to a project and can lead the meeting
• Scrum also includes the involvement of people who are not
committed to a project. For example, a VP, a salesperson or a
developer can just participate to listen
• It is an excellent way to share the information among the
participants

© 2019 IBM Corporation

97
Agile Training Module

• Each scrum team member answers the following three questions:

• What you did yesterday?
• What you will do today?
• Is there any hurdle blocking your work?
• Each one in the scrum team should take a maximum of three
minutes to answer the above questions. The first two questions are
about progress and the last one is about clearing the path of
progress
• The questions are asked from each person, one by one
• The raised issues are taken to the concerned subgroup immediately
after the meeting
• During the daily scrums, the team gets an excellent understanding
about each other’s accomplishments and plan the future.
• It’s a meeting to sketch the impending plans instead of getting the
project status or questioning the one who is lagging behind
• The scrum master is responsible for resolving any impediments that
are raised in the meeting. If he can’t, at least he ensures someone
else does.
• An interesting trend is to talk through the backlog of one product
item and then moving to the next. This allows multiple updates from
an individual in a single meeting.

Daily scrum meeting template:

© 2019 IBM Corporation

98
Agile Training Module

6.1.3: Product Backlog Refinement (PBR)/Grooming

Product Backlog Refinement, also referred to as Product Backlog

Grooming, is a method for keeping the backlog updated, clean and orderly.
It is a basic process in Scrum. PBR is a collaborative discussion process
which starts at the end of one sprint to confirm whether the backlog is
ready for the next sprint.

Backlog can be defined as a set of user stories which are not present in the
current sprint that defines project’s scope context. The stories which are
left unattended, may interfere with the functioning of the development
team. When this happens, the status of user stories will not be clear, and
even the team can lose focus and fail to deliver within the project
completion date.

The backlog grooming meeting is attended by the scrum master, who

facilitates everything for team members, the team and the product owner.
They decide among the top items from the product backlog. The team
comprises mainly of Developers, testers and Scrum Masters. The team can
raise queries during the sprint planning session if they find any unresolved
issue.

It will be easy for the product owner, to get the conclusion over the
queries, by asking the questions in the early stages. If there is a question
which is unanswered by too many people, it is time to make some changes
in your backlog items by curating higher priority items to the top of the list
and assigning highest priority to the unanswered questions.

The Objective of PBR meeting:

A lot of time is saved at sprint planning meetings, if the backlogs are well
maintained. If the backlog item is clearly specified in the acceptance
criteria and cross-checked properly by the team members, the planning

© 2019 IBM Corporation

99
Agile Training Module

process can be accomplished prior to the meeting. PBR offers the team
members the opportunity to interact with each other regarding stories.

Importance of PBR:

PBR and its sessions are important mainly due to the following features-

• It increases the efficiency of the team by reducing uncertainty.

• Properly refined stories are easy to estimate, test and implement.
• PBR session increases the efficiency of the team due to the
knowledge shared among the team members.
• If PBR meeting is maintained properly, it helps reduce the time for a
Sprint planning meeting.

The Product Backlog grooming can be made effective if the following

aspects are considered-

• Do not schedule backlog refinement meeting during the first and last
20% of the Sprint Planning session.
• Backlog refinement meeting should be considered as the first part of
Sprint Planning.
• The backlog items’ list should be well understood by the PO, or
development team member to work well in the meeting. Make sure
that the set of predefined acceptance tests are present.
• Keep an eye on the meeting goals.
• Make sure to assign action items for any unknown thing.
• Do remember that the backlog items are a collaboration between
the PO and the team.
• Feel free to break the product backlog items during the meeting.

After the product backlog refinement meeting, the team can update the
Product Backlog items in line, based on the discussions held. Finally, you
can get a potentially shippable product, ready to be deployed in the
market.

© 2019 IBM Corporation

100
Agile Training Module

Product Backlog Refinement Flow chart:

© 2019 IBM Corporation

101
Agile Training Module

© 2019 IBM Corporation

102
Agile Training Module

6.1.4 Sprint Review / Demonstration meeting

Sprint Review meeting is carried out once the Sprint has been done. It is
meant to inspect the Increment and adapt the Product Backlog if
necessary. When the Sprint Review meeting is taking place, the Scrum
team and stakeholders evaluate what has been done during the Sprint.

The review serves for sharing information, this is not a status meeting. It is
solely held to get some feedback as well as ensure that there is
collaboration.

During a Scrum, regular sprint review meeting is scheduling to demo and

determine the product usability. Teams are expected to deliver a
shippable product during each increment or Sprint.

To ensure their success, sprint review meeting is held at the end of each
sprint. During the review, the Scrum team shows to the stakeholders what
they have accomplished by demonstrating the newly designed features.

Sprint review meetings are deliberately informal. Programs like

PowerPoint are forbidden and a preparation time limit of 2 hours
maximum is set. These meetings are not, nor should they be viewed as a
distraction or major detour for the team. Instead, they should be a natural
transition and result of the sprint session.

Typically, the Scrum Master, members of the management team, the

product owner, customers, developers from other projects, and the Scrum
team participate in the sprint review meeting.

A goal for the software is set in the sprint planning meeting. Achieving this
sprint goal is very important. To ensure this has been done, the delivered
project is assessed and compared to the goal during the sprint review.
Each product backlog is also brought into the review to ensure that the
goal has been met.

© 2019 IBM Corporation

103
Agile Training Module

Sprint Review Meeting:

In a Sprint Review meeting, the Scrum Team and stakeholders discuss the
work done during the Sprint. After assessing the work done along with
changes made to the Product Backlog, the group collaborates on what
steps should be taken next to optimize the value of the software. These
meetings are always intentionally informal to keep the group focused on
encouraging feedback and collaboration.

For month-long Sprints, review meetings should last a maximum four

hours; referred to as time-boxed sessions. If the sprint sessions are
shorter in duration, the review meetings will also be shorter. The Scrum
Master is responsible for scheduling the meeting and informing everyone
attending of the purpose of the review. The Scrum Master is also
responsible of ensuring the meeting stays within the time-box.

The Sprint review meeting should include the following:

• Attendance and participation of the Scrum Team, product owner,

and invited key stakeholders.
• The Product Owner should report the items in the Product Backlog;
what backlog items have been done and what have not.
• The development team discusses what went well and the problems
they experienced. They should also inform the group what they did
to resolve the problems.
• The development team demonstrates their completed work while
answering questions about their increment.
• The product owner leads the discussion on the Product Backlog as it
currently stands. They set projected completion dates based on the
progress of the Sprint session.
• To give valuable input to the Sprint planning, the entire group
establishes the next steps during the Sprint review meeting.

© 2019 IBM Corporation

104
Agile Training Module

• This is a time to review potential changes in the marketplace, the

valuation of the project and what areas are considering to be the
most valuable. The next steps should also be outlined.
• Review the timeline, budget, potential capabilities, and marketplace
to determine the next anticipated product release.

By the end of the Sprint Review, revisions should be made to the Product
Backlog to better define probable backlog items for the next Sprint
session. The Product Backlog can be adjusted completely to introduce
new opportunities.

6.1.5 Sprint Retrospective

The sprint retrospective is a meeting facilitated by the Scrum Master at

which the team discusses the just-concluded sprint and determines what
could be change that might make the next sprint more productive. The
sprint review looks at what the team is building, whereas the retrospective
looks at how they are building it.

The sprint retrospective is an important mechanism that allows a team to

continuously evolve and improve throughout the life of a project. It is
important that everyone, including the team, product owner, and Scrum
Master, get a chance to air their opinions in an open, honest, yet
constructive atmosphere. It often also helps management to get feedback
from the team about the work and progress of project.

Retrospectives aren't used to record complaints - rather efforts are made

by the team to find effective solutions to problems and develop action
plans

Meeting specifics

Time box:

• 2 hours (2 weeks sprint) / 4 hours (4 weeks sprint)

© 2019 IBM Corporation

105
Agile Training Module

Attendees:

• Scrum Master
• Product Owner
• Scrum Team

When:

• At the end of sprint

How is Sprint Retrospective held?

The Sprint Retrospective is held after the sprint review at the end of each
sprint. During the retrospective, the team self-identifies elements of the
process that did or did not work during the sprint, along with potential
solutions. It aims to continuously improve the processes. Sprint
Retrospective meetings can be facilitated by asking each person in the
team to answer the following questions.

• What went well during the sprint?

• What would we like to change?
• How can we implement that change?

Alternatively, instead of asking what went well and what didn’t go well, the
following questions may be asked:

• What should we start doing?

• What should we stop doing?
• What should we continue to do?

© 2019 IBM Corporation

106
Agile Training Module

Benefits of Retrospective:

Process improvements are made at the end of every sprint. This ensures
that the project team is always improving the way it works.

• The retrospective is a collaborative process among all members,

including the team, the product owner, and the Scrum Master.
• All team members identify what went well and what could be
improved.
• The team members discuss the process that they are following and
give any suggestions for improvement.
• The team members discuss any other ideas that could improve their
productivity.
• The Scrum Master prioritizes actions and lessons learned based on
team direction.
• The retrospective supports team formation and bonding, particularly
as any areas of conflict can be identified and dealt with.
• The retrospective helps build the team's sense of ownership and its
self-management.

© 2019 IBM Corporation

107
Agile Training Module

Tips for effective Retrospective

Following are the tips for the effective retrospective:

• Review notes and actions from the previous retrospective.

• Ask what problems, successes and opportunities you have with the
team, the product, and the process.
• Let each team member speak without discussion.
• Vote on the most important items to act on.
• Use “five whys” to discover the root cause of problems.
• Create an action plan for your top priority items.
• Explicitly allocate time for improvement actions.
• Record your retrospectives & actions

Sprint Retrospective Template:

Team / Iteration Retrospective Type What Category Comments

Person Item actions are
we take to
improve the
bad/ugly
things, and
continue
doing the
good ones?
1
2
3
4
5

© 2019 IBM Corporation

108
Agile Training Module

Exercise 1: Quick recap of Scrum Ceremonies

Introduction: This exercise will help to understand the various Scrum
Ceremonies.
Procedure:
• Divide the entire team into 4 sub groups.
• Ask them to name their group
• Each sub group should have equal no of participant
• Give the topics to each sub groups as
a) Sprint Planning
b) Daily Scrum
c) Sprint Review
d) Sprint Retrospective
• Give one-one chart paper, Markers to each sub team
• Team must put their Group name on the Top of the chart sheet
• Ask the participant to divide the entire sheet into 4 quarters like
below

© 2019 IBM Corporation

109
Agile Training Module

Purpose: Time Box:

Participant: When:

• Each team will first write the Input and Output for their respective
topics like if Team A has got the topic as “Sprint Planning” then they
should write what are the inputs for Sprint Planning and what will be
the output.
• After that they must fill the necessary information in each box i.e in
“Purpose”: They must mention the purpose of their respective
topics.
In “Time Box”: Duration of that ceremony
In “Participants”: Who all are required for this
In “When”: Frequency or time of occurrence
• Give 5 Mins for discussion
• After that give 10 mins to fill the chart
• Call any one of the Sub team to display their thoughts in the board
and explain to everyone regarding that ceremony.
• Ask other teams at the end if the team missed out any point

© 2019 IBM Corporation

110
Agile Training Module

• Likewise call each team to explain their thoughts.

Note:
Logistics: 1 Display board
4 chart papers
8-10 Markers (Each Team 2 different color Markers)

Test Your Knowledge:

2. In a 30-day Sprint, how long is the Sprint Review Meeting?
a) Maximum 4 hours
b) Four to eight hours
c) At least 8 hours
d) As long as required

3. The time box for a Daily Scrum meeting is?

a) 30 mins
b) 2 mins per person
c) 4 hours
d) 15 mins
4. The time box for a sprint planning meeting for a 1month Sprint
is?
a) 8 hours
b) Max 8 hours
c) Min 8 hours
d) 2 hours per week of Sprint
5. In which meetings can design be discussed?
a) Daily Scrum Meeting
b) Sprint Review Meeting
c) Sprint Planning Meeting
d) Sprint Retrospective meeting

© 2019 IBM Corporation

111
Agile Training Module

6. Sprint Review is a formal review of the product by Product

Owner.
a) True
b) False

© 2019 IBM Corporation

112
Agile Training Module

Chapter 7: Scrum Sprint Planning

7.1 Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through
the implementation of Product Backlog. Sprint goals are the result of a
negotiation between the Product Owner and the Development Team.
Sprint Goals should be specific and measurable. While the selected work
for the Sprint Backlog represents a forecast, the Development Team gives
their commitment to achieving the Sprint Goal.

Benefits of Sprint Goal:

• Provides guidance to the Development Team on why it is building the

Increment.
• Serves to test assumptions, address risks or deliver features
• Ensures a focused Daily Scrum because the Development Team can use
it to inspect their progress.
• Helps setting priorities when "the going gets tough”.
• Enables efficient decision-making.
• Fosters teamwork and teambuilding by jointly working towards a shared
Sprint Goal
• Supports the Product Owner in creating the product roadmap
• Stimulates Product Backlog cohesion when planning a release
• Can be used as an instrument for stakeholder management
• Supports a focused Sprint Planning by crafting a shared Sprint Goal
• Offers flexibility regarding the functionality implemented within the
Sprint.

Determine Sprint Goal:

To determine what the Sprint Goal should be, we should consider the
three questions:

© 2019 IBM Corporation

113
Agile Training Module

• Why do we carry out the Sprint? Why is it worthwhile to run a sprint?

What should be achieved?
• How do we reach its goal? Which artefact, validation technique, and test
group are used?
• How do we know the goal has been met? For instance, at least three of
the five users carry out the usability test successfully in less than a
minute.

Sprint Goal is the outcome of the Sprint Planning Meeting.

The Sprint goal is typically defined in the first part of the Sprint Planning
Meeting in the following main steps:

© 2019 IBM Corporation

114
Agile Training Module

• Product owner presents the ordered backlog items to the team.

• Team discusses and understands the work for this Sprint.
• Team forecasts and commits on the items that can be done.
• Team creates the Sprint Goal for this Sprint.
Sprint Goal Template

© 2019 IBM Corporation

115
Agile Training Module

7.2 User Stories

Definition:
A user story is a very high-level definition of a requirement, containing just
enough information so that the developers can produce a reasonable
estimate of the effort to implement it.
An Agile user story is meant to be short, usually fitting on a sticky note or
note card. The user stories should be written by the business in the
language of the customer so that it is clear to both the business and the
development team what the customer wants and why he wants it. The
development team's job is to take care of how to develop the code that
will satisfy the requirements of the user story. In best-case scenarios,
developers collaborate closely with the business owners to clarify the
details as the code gets developed.

User Stories Template:

A user story template often uses the following type of format:
As a <role>, I want <feature> so that <reason>.

Example:

As a user, I want to upload photos so that I can share photos with

others.

As an administrator, I want to approve photos before they are posted

so that I can make sure they are appropriate.

© 2019 IBM Corporation

116
Agile Training Module

Why you should write a user story:

As a Product Owner (PO) when you receive a user story from any source
you should be asking yourself to follow questions
1) Why are we doing this, what is the business or technological gain?
2) What is it for, who will be user using it, remember the 80/20 rules? If
you are spending too much effort on providing the feature which is either
not requested by many users or doesn’t add much value.
3) What value does it drive, what is monetary, user, or UX gain of that user
story?
4) what’s your estimates on time to implement?
5) what are the acceptance criteria or CoS (condition of satisfactions)?
6) what testing will be needed?
7) What support can you give?
8) what is your marching order, does the story fit well in the marching
order?
Product owner and the team should decide on what they feel is the most
appropriate way to describe the work that needs to be done. As team
know how part and PO knows the what part.

Benefits of writing user stories

• Helps to express the business value.

• Avoid introducing detail too early that would prevent design options and
inappropriately lock developers into one solution.
• Avoid the appearance of false completeness and clarity.
• Get to small enough chunks that invite negotiation and movement in the
backlog.
• Stories are comprehensible.
• Developers and customers understand them.
• People are better able to remember events if they are organized into
stories.
• They support and encourage iterative development.

© 2019 IBM Corporation

117
Agile Training Module

• They can be easily started as epics and later disaggregated at the

development time.
• Stories support opportunistic development.
• Stories support participatory design.
• Stories put the focus on the user’s goals
7.3 Estimate User Stories

Agile emphasis to estimate a story in Story point instead of hours.

What is a Story Point?

Story points represent the relative sizing of the user story. It is a unit of
estimation used by Agile teams to estimate User Stories.

When the product owner wants some features to be developed he/she

desires to know how soon the team can complete the features and how
many resources it will take to complete the work. From the developer’s
perspective it’s next to impossible to predict the exact time in which
he/she can complete the work. The person can, however, give a rough
estimate in terms of how much time it might take to complete the work.
Note that instead of “will” the developer chose to use “might” because
he/she is not absolutely “sure” about the time factor but “feels” it might
take that much time. This is user story estimation in a nut shell.

You don’t give an exact number explaining how complex the story is and
how long it’ll take to develop – you give a rough “estimate”.

We are good at comparing size, so estimating a story using Fibonacci

series sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, and 100) gives more clarity of
its complexity and relative sizing in terms of development. It is helpful to
have a set of stories nearby to make comparison and recommendation to
set priority.

© 2019 IBM Corporation

118
Agile Training Module

Here are the examples of relative sizing and its estimation points to
develop following vehicles:

Factors to be consider while estimating stories:

• Complexity: Consider the complexity of the story.

• Risk: Consider the team’s inexperience with developing this story.

• Implementation: Consider the implementation factors.

• Deployment: Consider the deployment requirements.

• Interdependencies: Consider other outside issues.

Participants in story Point estimation:

All team members who are responsible for getting a story done should
ideally be part of the estimation.

Advantages of using story points for estimating work:

• Story points are a measure of relative size and complexity.

© 2019 IBM Corporation

119
Agile Training Module

• Story points are unit less, meaning as a scale, they are only valuable to
compare against each other within the same team.

• Estimating in story points allows/encourages everyone, including

business people to participate in the estimation process (using Planning
Poker).

• Estimating in story points is fast and easy.

• Story points initiate high-level discussions about everything that is

involved in a project.

• Earned points can be used to generate the team’s velocity which can be
used to predict future work capacity.

Steps to estimate stories

For each story to be sized, do the following as a team (Product Owner,

Scrum master & Team member).

1. Identify base stories:

Identify one or multiple base or reference story against which you would
do relative sizing of the backlog. This story is picked from current product
backlog or a different story which we have done earlier. But what is
important is the understanding of this story is same among everyone on
the team. Team should be confident of this base story.

2. Talk through the detailed requirements

Product Owner will answer questions and provide explanation about what
exactly this story entails.

3. Discuss and note down points

© 2019 IBM Corporation

120
Agile Training Module

These can be bullet points on the story card or text in the “notes” section
of a tool. This is best done by Scrum Master who can add these details as
and when discussions are on.

4. Raise questions if any

During discussion, question may arise and must be clarified the same
time. Such as

• Requirement: Any doubt about story requirement? Raise an alert. Ask

product owner to give more clarity.

• Technical Feasibility: Can story be delivered using current technology?

Any unforeseen technical challenges must be surfaced.

• Acceptance Criteria: Team must clarify the check list to be fulfilled to

mark story as accepted.

• Dependency: Does this story have external dependencies? If yes, that

must be understood and resolved quickly.

• Expertise: Do we have enough skills to deliver the story? Team must

have internal skills to deliver story otherwise delivery might be delayed
or not done properly.

5. Agree upon estimated size

Every team member must agree upon estimated size decided for a story.

© 2019 IBM Corporation

121
Agile Training Module

7.3 Definition of Done

In order to be able to decide when an activity from the Sprint Backlog is

completed, the Definition of Done (DoD) is used. In simple terms,
Definition of Done is a simple list of activities (writing code, coding
comments, unit testing, integration testing, release notes, design
documents, etc.) that add verifiable/demonstrable value to the product. It
includes a comprehensive checklist of necessary activities that ensure
that only truly done features are delivered, not only in terms of
functionality but in terms of quality as well. Focusing on value-added
steps allows the team to focus on what must be completed in order to
build software while eliminating wasteful activities that only complicate
software development efforts. The DoD may vary from one Scrum Team to
another but must be consistent within one team.

There might be different DoD at various levels:

1. DoD for a user story (e.g. writing code, tests and all necessary
documentation)
2. DoD for a sprint (e.g. install demo system for review)
3. DoD for a release (e.g. writing release notes)

There are various factors which influence whether a given activity belongs
in the DoD for a feature, a sprint or a release. Ultimately, the decision rests
on the answer to the following three questions:

1. Can we do this activity for each feature/story? If not, then

2. Can we do this activity for each sprint? If not, then
3. We have to do this activity for our release

© 2019 IBM Corporation

122
Agile Training Module

Story Definition of Done

What must happen for the story to be marked as complete:

• All story should have automated acceptance test.

• The story should have working code supported by unit test that
provide around 60 – 70 percent coverage.
• The story should have well defined acceptance criteria.
• The code must have been written as a pair or should be code
reviewed.
• Code must be completely checked in to the source control system
and the build should pass with all the automated tests running.
• The product owner must accept the story.

Sprint Definition of Done

• Product owner should have defined a sprint goal.

• All stories completed for the spring must be accepted by the
product owner.
• All the automated acceptance tests should be running for the
stories in the sprint.
• All code should have been pair programmed or must have gone
through a code review process.
• If there is a database involved, the database scripts must have
been automated and tested.

Release Definition of Done

• Product is deployed to the test box and makes it to staging.

• There are deployment documents for the release.
• Training manuals are available for users.
• All stories for the release are completed and accepted.
• The release does not have any level one bugs.

© 2019 IBM Corporation

123
Agile Training Module

The evolving Definition of Done

A team’s Definition of Done won’t remain the same throughout the lifetime
of the project and neither should it. As the team becomes more effective
and productive and learns to work better, it will naturally enhance and
refine its Definition of Done to produce more valuable and better-quality
features. It will start recognizing patterns in the development processes
and procedures required to produce high quality features, and it'll start
adding these to the DoD. It’s therefore important that the team gets
regular opportunities to revisit the Definition of done and the natural place
to do this is in the sprint retrospective meeting.

Definition of Done common impediments

Some of the common root causes for impediments are:

• Team does not have the skill set to incorporate activities into the
definition of done for a sprint or for a feature.
• Team does not have the right set of tools. (Example: continuous
integration environment, automated build, servers etc.)
• Team members are executing their sprint in mini-waterfalls. Aha!
Opportunity to be more cross-functional. Sharing of
responsibilities across functional silos.

Exercise 2: Effective estimation of User story

Introduction: This exercise will help to estimate the user story based on
their knowledge.
Give a User story and ask the team to do the estimation.
Sample User story: Login to a bank website where one can view the last 10
transactions.

© 2019 IBM Corporation

124
Agile Training Module

Procedure:
• Divide the entire team into 4-5 sub groups.
• Ask them to name their group
• Each sub group should have equal no of participant
• Give 5 Mins for discussion
• After that give 10 mins to estimate the user story.
• Call any one of the Sub team members and ask him/her to tell the
story points and explain how they calculate, what are the
parameters they have consider while estimating the User story.
• Repeat it for other teams.
Note: Team has to choose any one number (0,1,2,3,5,8,13,20,40 and
100)

© 2019 IBM Corporation

125
Agile Training Module

Test Your Knowledge:

1. Who should decide the Definition of Done?

a) Product Owner
b) Scrum Master
c) Product Owner and Dev team
d) Product Owner and Scrum Master

2. Which is the ideal meeting to adapt the Definition of Done?

a) Sprint Planning
b) Daily Scrum
c) Sprint Review
d) Sprint Retrospective
3. Who defines the User stories?
a) Dev team
b) Scrum master
c) Product Owner
d) All of the above
4. User stories are estimated based on?
a) Hours
b) Story points
5. A user story is a very high-level definition of a requirement.
a) True
b) False

© 2019 IBM Corporation

126
Agile Training Module

Chapter 8: Scrum Metrics

8.1 Sprint Goal Success

On an agile project, metrics can be powerful tools for planning, inspecting,

adapting, and understanding progress over time. Rates of success or
failure can let a scrum team know if it needs to make positive changes or
keep up its good work. Time and cost numbers can highlight the benefits
of agile projects and provide support for an organization’s financial
activities. Metrics that quantify people’s satisfaction can help a scrum
team identify areas for improvement with customers and with the team
itself.

Sprint Goal Success Rates:

One way to measure agile project performance is with the rate of sprint
success. The sprint may not need all the requirements and tasks in the
sprint backlog to be complete. However, a successful sprint should have a
working product feature that fulfils the sprint goals and meets the scrum
team’s definition of done: developed, tested, integrated, and documented.

Throughout the project, the scrum team can track how frequently it
succeeds in reaching the sprint goals and use success rates to see
whether the team is maturing or needs to correct its course. Sprint
success rates are a useful launching point for inspection and adaptation.

© 2019 IBM Corporation

127
Agile Training Module

8.2 Team Velocity

The Velocity indicates the amount of value delivered in each sprint,

enabling you to predict the amount of work the team can get done in
future sprints. It is useful during your sprint planning meetings, to help
you decide how much work you can feasibly commit to. The team's
velocity can be estimated based upon the total estimate (for all completed
stories) for each recent sprint. This isn't an exact science — looking at
several sprints will help you to get a feel for the trend. For each sprint, the
Velocity Chart shows the sum of the Estimates for complete and
incomplete stories. Estimates can be based on story points, business
value, hours, issue count, or any numeric field of your choice.

Let's say the product owner wants to complete 500 story points in the
backlog. We know that the development team generally completes 50
story points per iteration. The product owner can reasonably assume the
team will need 10 iterations (give or take) to complete the required work.

It's important to monitor how velocity evolves over time. New teams can
expect to see an increase in velocity as the team optimizes relationships
and the work process. Existing teams can track their velocity to ensure
consistent performance over time and can confirm that a particular
process change made improvements or not. A decrease in average
velocity is usually a sign that some part of the team's development
process has become inefficient and should be brought up at the next
retrospective.

© 2019 IBM Corporation

128
Agile Training Module

Each team’s velocity is unique. If team A has a velocity of 50 and team B

has a velocity of 75, it doesn't mean that team B has higher throughput.
Since each team's estimation culture is unique, their velocity will be as
well. Resist the temptation to compare velocity across teams. Measure the
level of effort and output of work based on each team's unique
interpretation of story points.

© 2019 IBM Corporation

129
Agile Training Module

Importance of velocity

Velocity is a key feedback mechanism for the Team. It helps the team to
measure whether process changes it makes are improving its productivity
or reducing it. While a Team's velocity will oscillate from Sprint to Sprint,
over time, a well-functioning Scrum Team's velocity should steadily trend
upward by roughly 10% each Sprint.

It also facilitates very accurate forecasting of how many stories a Team

can do in a Sprint. For forecasting purposes, the average of the last three
Sprint's Velocity should be used. Of course, this means it takes three
Sprints of experience for a Team to determine its Velocity accurately,
which can sometimes be difficult to explain to impatient stakeholders.
Without Velocity, Release Planning is impossible. By knowing Velocity, a
Product Owner can figure out how many Sprints it will take the Team to
achieve a desired level of functionality that can then be shipped.
Depending on the length of the Sprint, the Product owner can fix a date for
the release.

The velocity metric is used to reconcile velocity changes - an increase in

accepted bugs or chores can explain a dip in velocity. It’s also helpful for
managing technical debt: keeping chores at a steady level ensures a focus
on keeping your systems and code in peak condition. There are several
things you can do with a velocity chart:

Monitor overall project health

The Velocity chart visualizes a number of project trends: iteration velocity

(including average velocity), accepted stories by type, and volatility
metrics. This makes the Velocity chart an ideal gut check for overall
project health.

© 2019 IBM Corporation

130
Agile Training Module

Understand velocity trends

Accepted points may be low for a particular iteration when there is a large
number of bugs, chores, or zero-point stories. The Velocity chart makes
these “bug/chore walls” visible by showing iteration velocity dips
alongside an increase in accepted bugs.

Track volatility

Volatility is a relative measure of predictability. Frequent velocity peaks

and valleys may imply an unpredictable project, whereas smoother
iteration-by-iteration velocity suggests a more predictable one.

Why do we need velocity?

• Predict how much scope can be delivered by a specific date.

• Predict a date for a fixed amount of scope to be delivered.
• Understand our limits while defining the amount of scope we will
commit for a sprint.

Can an incomplete user story be counted in velocity?

No, you shouldn't. Incomplete is undone. Velocity is about finished,

delivered user stories. Here are some reasons why you shouldn't count
incomplete user stories:

• We can't really figure out how much ready and how much is not; it
will be a wild guess.
• We may be led by a false sense of accuracy, due to the use of
fractional numbers.
• Incomplete means the user story still has no value for the customer.

© 2019 IBM Corporation

131
Agile Training Module

Determining team velocity

An existing team can determine its velocity by completing the following

steps :

• Agree on a project iteration (for example, 10 workdays).

• Gather a list of what the team completed in the previous 10 work
days.
• List the work completed in story points to establish their sum and
corresponding velocity value.
• Plan to deliver this number of story points in the team's first
iteration.
• Add or remove points in the next iteration based on whether the
team completes the targeted number of story points.

Most teams determine their baseline velocity within about three iterations.

8.3 Sprint Burn Down Chart

Definition

The Sprint Burndown Chart is a visual measurement tool that shows the
completed work per day against the projected rate of completion for the
current sprint. It provides transparency about the current performance
(burndown rate) and allows easy estimation if the Sprint Goal can be
reached in time or if the team has to find additional measures to speed-up
completion of the remaining activities. The rate of progress of a Scrum
Team is called "velocity". It expresses the amount of work in story points
completed per sprint. An import rule for calculating the velocity is that
only stories that are completed at the end of the sprint are counted.
Counting partially finished work (e.g. coding only - test missing) is strictly
forbidden.

© 2019 IBM Corporation

132
Agile Training Module

What does a Burndown chart show?

• Total Estimate

It is the sum of efforts in hours of all the user-stories, tickets, and issues,
basically it’s the total number of works in hours to which the team is
committed to.

• Amount of work Remaining or Effort Remaining

This is what burn down shows and this is how this graph get its name, in
literal meaning it is the “effort burndown chart”. The Team will burndown
some effort each day so that on last day of sprint or release there is no
work effort remains.

• Working Days

Since team need to calculate and carefully work on the commit item each
day, so that is the reason total days of commitment of work are shown in
graph. This is the total working days in a sprint (excluding holidays,
weekend, etc.). This is actually your sprint duration.

• Ideal Effort

The ideal effort is drawn as a guide for a team, its drawn by calculating the
exact amount of effort remaining which team need to burndown. That is
the reason you see a very straight line from the top of Y-axis to X-axis,
which is the last day of your sprint.

• Real Effort

Effort remaining line varies from team to team and day to day. It depends
on how much effort remaining is added or reduced each day. If more items

© 2019 IBM Corporation

133
Agile Training Module

(user stories and issues) are added after the sprint started, this show as an
upward spike.

The chart can help in answering the following questions:

• How good is this team with the planning?

• How well is this team executing against the planned stories in a
Sprint?
• Is this team self-organized and are they working in unison as a
"team"?
• What improvements can this team make?

Steps to read Burndown chart:

The burn down chart is simple to understand:

• X axis for days of the sprint

• Y axis for effort (story points or hours or days depending on what you
prefer)
• Ideal line that visualize expected progress
• Real line visualizing the current progress

At the start of an iteration the team estimates the work for all the tasks it
commits to. The sum of all the hours estimated in story points for all the
tasks is the starting point for the graph. Every day as the team members
work on tasks, the remaining work plotted on the chart should also
reduce. The chart should be updated each day and the graph should
ideally displays a downward trend. What makes the chart an effective
reporting tool is that it shows the team's progress towards the Sprint Goal,
not in terms of time spent but in terms of how much work remains.

© 2019 IBM Corporation

134
Agile Training Module

Samples Burndown chart:

The following samples show the team status based upon the Burndown
chart.

Type 1: Sprint commitment met

A burn-down chart in which sprint commitments are met and progress has
been smooth over the sprint.

Type 2: Sprint commitment not met

The teams are going at a slower pace and may not be able to complete all
the commitments on time. The remaining work then becomes a part of the
product backlog and is carried forward to subsequent sprints.

© 2019 IBM Corporation

135
Agile Training Module

Type 3: Sprint commitment met early before time

It shows that we are going at a better rate and may be able to finish
earlier. The stories were probably overestimated; therefore, the team
finished them earlier.

Advantages of using Burndown charts:

• Single planning and tracking tool for the team

The team performs task breakdown, updates the estimated effort, and
also updates the effort remaining. The entire team drives planning and
tracking using the burn-down tool, which is the biggest advantage of using
it.

• Risk mitigation by daily visibility

The burn-down chart provides daily feedback on effort and schedule,

thereby mitigating risks and raising alarms as soon as something goes
wrong, rather than waiting till the end.

• Communication tool for customer and other stakeholders

© 2019 IBM Corporation

136
Agile Training Module

Burn-down charts provide visibility of a project’s progress on a daily basis.

In the absence of an online tool, burn-down can be physically represented
using a whiteboard/chart paper.

• Placeholder to track retrospective action items

It is a good practice to include retrospective action items from the

previous sprint as "functional requirements" in the task breakdown for the
current sprint. This way, the team keeps a focus on those action items and
they are tracked as the sprint progresses.

Common mistakes while using Burndown charts:

• If the task is too big, then it will make tracking on a daily basis
difficult.
• People get confused with the effort spent and the effort remaining. If
these are wrongly plotted, then the report insight will be inaccurate.
• Forgetting to update the remaining time for tasks will lead to
incorrect data.

© 2019 IBM Corporation

137
Agile Training Module

8.4 Defect Density:

Definition:

Defect Density is the number of defects confirmed in software/module

during a specific period of operation or development divided by the size of
the software/module. It enables one to decide if a piece of software is
ready to be released.

Defect density is counted per thousand lines of code also known as

KLOC(Kilo Lines Of Code).

Formula to measure Defect Density:

Defect Density = No of defects/Size of the Release

Size of release can be measured in terms of a line of code (LoC).

Example:

Suppose, you have 3 releases integrated into your software product. Each
release has the following number of bugs discovered-

• Release 1 = 5 bugs
• Release 2 = 15 bugs
• Release 3 = 8 bugs

Total bugs = 5+15+8 =28

The total line of code for each release is

• Release 1 = 2000 LOC

© 2019 IBM Corporation

138
Agile Training Module

• Release 2 = 1200 LOC

• Release 3 = 800 LOC
Total Line of Code = 2000+1200+800 = 4000
Defect Density is calculated as:
Defect Density = 28/4000 = 0.007 defects/loc = 7 defects/Kloc
Advantages of defect density

• It helps to measure the testing effectiveness

• It helps to differentiate defects in components/software modules
• It is useful in identifying the areas for correction or improvement
• It is useful in pointing towards high-risk components
• It helps in identifying the training needs to various resources
• It can be helpful in estimating the testing and rework due to bugs
• It can estimate the remaining defects in the software
• Before the release, we can determine whether our testing is
sufficient
• We can ensure a database with a standard defect density

Factors that affect the defect density metrics

• Code complexity
• The type of defects considered for the calculation
• Time duration which is considered for Defect density calculation
• Developer or Tester skills

Exercise 3: Where do I Stand?

Introduction: This exercise will help to make the team understand the
importance of the characteristic of Agile.
“ Self-Organization is a characteristic of Agile teams”
Procedure:
• Ask the participants to arrange themselves in a queue by
How much time they take to come from home to the training Venue?

© 2019 IBM Corporation

139
Agile Training Module

• Let the participants decide the way they want to stand (ascending or
descending order)
Note: This exercise helps the participant to understand self-organization
Instructor should not give any clue.

Test Your Knowledge:

1. When is the sprint finished?
a) As determined by the size of the Dev Team
b) When tasks are completed
c) When the time box expires
d) When committed items have met their Definition of Done

2. Team velocity defined based on story point delivered on

previous sprints.
a) True
b) False
3. The value delivered by a product can only be determined by
revenue.
a) True
b) False
4. Ground rules are set by?
a) Product Owner
b) Scrum Master
c) Dev Team
d) Sponsor
5. The following best describes the defect density:
a) Ratio of failure reports received per unit of time.
b) Ratio of discovered errors per size of code.
c) Number of modifications made per size of code.
d) Number of failures reported against the code

© 2019 IBM Corporation

140
Agile Training Module

Chapter 9: Additional Info

9.1 Scaling Scrum

According to Craig Larman and Bass Vodde (the creators of LeSS) the
primary rule of scaling agile is: don’t do it!

If you have problems with:

• Cross team dependencies

• Risks that affect several teams
• Scheduling of (coordinated) deliveries

you might need a scaling framework. If you can deal with these problems
by re-arranging your teams and product structure, you are better off
without one. If you can’t, please continue reading.

Commonly used Scaling frameworks

Most commonly used frameworks are

• LeSS
• SAFe
• Scrum@Scale

All three frameworks start with cross-functional, self-organizing Scrum

teams. The teams vertically slice requirements into the smallest possible
increments that can be deployed independently. Teams are also expected
to focus on technical excellence such as doing continuous integration and
automated regression testing. At the end of every sprint the teams should
have a potentially deployable product. The three frameworks also
encourage you to use Lean principles to optimize your flow.

© 2019 IBM Corporation

141
Agile Training Module

LeSS (Large Scale Scrum)

At its most basic level, LeSS is a clarification of how Scrum is intended to

work. For example, it clarifies that Scrum teams should be long-lived
cross-functional feature teams that are maintained across multiple
projects. The idea is to manage the complexity of large-scale development
by simplifying it as much as possible. Therefore, LeSS recommends that
multiple teams has the same Product Owner and a shared Product
Backlog. Their sprints are synchronized to the Product-level Sprint leading
to one integrated Potentially Shippable Product Increment. Sprint
Planning, Sprint Review and Sprint Retrospective runs at the same time for
all teams.

One Product Owner with one product backlog, and several teams, each
with its own sprint backlog.

It might seem impossible for a single person to be a Product Owner for up

to eight teams, but the philosophy of LeSS precludes the Product Owner
from participating at a detail level, which leads to teams that take on the
responsibility to work out their own solutions. This forces the developers
to get closer to their users, giving them a better understanding of their
users' context, needs and problems. The result is a higher level of
involvement and custom solutions, developed with better quality more
efficiently. Simply put, you "get more with LeSS".

© 2019 IBM Corporation

142
Agile Training Module

Overview of LeSS with synchronized sprints

Process-wise, LeSS is pure Scrum (time-boxed iterations, sprint planning,

daily stand-up, sprint review, and retrospective), with a modification. As
per Scrum, Sprint Planning is split into two parts. However, LeSS
recommends that the first part is a joint meeting attended by
representatives from all of the teams to agree "What" Product Backlog
Items (PBIs) will be built in the coming Sprint. The second part of Sprint
Planning is then used by each team to produce the Sprint Backlog and
agree "How" the PBI's will be built.

© 2019 IBM Corporation

143
Agile Training Module

Common sprint end for all teams in LeSS

The end of the sprint also needs to be synchronized. This is accomplished

by having one common Sprint Review for all the teams. The Retrospective
is divided into two parts, similarly to the sprint planning. First, each team
holds their own individual team Retrospective, then representatives from
each team hold a joint Retrospective together that enables them to
identify and address issues that cannot be solved at the individual team
level.

© 2019 IBM Corporation

144
Agile Training Module

SAFe

SAFe’s central premise is to divide the work into value streams. A value
stream consists of the steps that the company continuously repeats to
deliver value to customers and users. Between 5 and 15 teams are
typically involved with a value stream, and this grouping of teams is called
a release train. A release train can contain up to 150 people. Once that
threshold is exceeded it is recommended to have several Agile release
trains within each value stream.

Agile release trains are an organizational structure, and the Release Train
Engineer’s roll is that of a facilitating coach (also known as an Agile Coach
in other organizations).

Process

Within the Agile Release Train, teams work according to Scrum with
sprints of typically 2 weeks.

SAFe also adds the concept of a “Program Increment” which is a cadence-

based interval of about 10 weeks, although the length of each interval may
vary.

The creators of SAFe recommend a Program Increment duration of

between 8 to 12 weeks based on their experience in the field.

© 2019 IBM Corporation

145
Agile Training Module

Week-by-week, the relationship between Sprints and Program

Increments

A Program Increment begins with the “PI Planning Event” (a.k.a. “big
room planning”) – a one to two days event where teams gather together to
plan for the next Program Increment (usually around 10 weeks). Typically,
product managers begin the meeting and set the vision followed by teams
do the actual planning and resolving dependencies between them. The
result of the planning, including dependencies between teams, is
visualized on a Program Board. If uncertainties arise, Product Managers
are constantly on hand to make an immediate decision. The Program
Increment is facilitated by a Release Train Engineer.

SAFe suggests two things for achieving a balance between predictability,

technical needs, and flexibility:

Not upfront plan any Backlog Items for the “Innovation & Planning Sprint”
(IP Sprint), the last sprint of the Program Increment. Instead use it to
finalize things that didn’t get finished, help product owners plan future
increments, and just try new things.

Do not fill the Sprints to 100% capacity, but rather only 30-70% to make
room for correcting defects, providing user support, and the unforeseen. It
also provides the capacity for accomplishing those things that product
management takes for granted, but often do not receive dedicated time,
for example, upgrading tools and adapting to new platforms.

© 2019 IBM Corporation

146
Agile Training Module

A typical Scrum team has three kinds of items in their sprint backlog:

1. Defects that are prioritized before anything else.

2. Items from the “big room planning”
3. Things the team knows ought to be done, but no one else has real
insight or opinion of (for example, upgrading operating systems or
databases).

Scrum@Scale

Scrum@Scale comes from one of Scrum's founders, Jeff Sutherland, and

is a meta-level framework that takes up the areas that need to be resolved
to bring Scrum to scale. One could see it as a list with discussions you
need to have when you decide your process. Depending on the context,
the solution may be similar to SAFe, LeSS or its own custom method.

© 2019 IBM Corporation

147
Agile Training Module

The areas are divided into a Product Owner cycle (red) and a Scrum Master
cycle (gray), as well as some principles on metrics and transparency.
Image courtesy of Jeff Sutherland and Scrum Inc.

Product Owner cycle

• Strategic Vision – Where are we heading with the company and our
products?
• Backlog prioritization – What is most important for us at the company
level, the portfolio level, and within the project?
• Backlog decomposition and refinement – How do we allocate the tasks
among the teams, and how do we conduct sessions in preparation for
them?
• Release Planning – How do we plan for our deliveries? What comes
when?

© 2019 IBM Corporation

148
Agile Training Module

• Release Management – How do we synchronize between teams to get

painless launches?
• Product and release feedback – How do we get feedback about the
latest launched features from the user, and how do we get that
information out to the teams?

Scrum Master cycle

• Cross-team coordination – How do we coordinate between different

Scrum teams so we’re not both doing the same thing or tripping over
each other?
• Continuous improvement and impediment removal – How do we
ensure that all teams are aware of their skills and constantly try to
improve them? How do we ensure that whatever a team comes upon
will be resolved even if it falls outside their area of competency?

Outside of these two cycles are also:

• Metrics and transparency – How do we measure that we build the

right things and how do we make sure that everyone has access to
these readings?

In some organizations, it can be very difficult to get to some

improvements unless people who have the authority to make certain
decisions are involved. Scrum@Scale proposes that companies set up a
group of decision makers (for example, an Executive Action Team) whose
mandate is to facilitate and oversee the improvements that the teams,
Product Owners, and Scrum Masters do not themselves have the ability to
implement.

9.2 Distributed Scrum Practices

© 2019 IBM Corporation

149
Agile Training Module

Distributed Agile: 10 Good Practices of Successful Teams

Distributed agile teams can exist in different forms like.

• Product Owner is onshore, Team is offshore

• Team split between two or more locations
• A complex model like product owner not with onshore team and
development team distributed across time zones

Top 10 good practices that are implemented by successful distributed

agile teams.

Meeting face-to-face is the only way to build trust

• Budget-in recurring face-to-face meetings between your customer,

local team, and offshore team
• Having strong communication infrastructure like Skype, Video Conf,
Phones, high bandwidth, big screens to facilitate virtual team etc.
• Seed visits in frequent intervals across the length of the project
• Both offshore and onshore teams sitting, working and partying together
is a must to ignite relations and build strong trust
• The highest performing teams are those based on trust

© 2019 IBM Corporation

150
Agile Training Module

Establish a shared project vision

• Participation in this activity by whole team emphasizes ownership of

the project results
• Use collocation travel as best opportunity to build this
• Doing release planning, sprint planning and daily scrum together by
team builds similar shared vision

Establish continuous integration (CI) with high test coverage across all
teams

• CI is important because it detects build issues immediately

• Avoids the classic “big bang integration” at the end of projects which in
my experience is the #1 reason for schedule slip
• Teams striving towards build-state always green, reduces
waiting/debug time between teams and hence build trust between
them.

Establish a synchronization and communication plan

• Define how customer, local team, and offshore team will communicate
and maintain synchronization
• Define daily and distributed stand-ups, retrospectives and sprint review
time

Establish a rigorous Norming and Chartering plan to achieve high

quality

• Set of activities the team will perform to absolutely insure and maintain
high-quality software
• Define consensus-based design, Coding standards, Code reviews,
Scrum-of-Scrums, Pair Programming, Source control philosophy,
Defect tracking mechanism, Definition of “Ready” and “Done” and
more.
• You can read this excellent post on Norming and Chartering

© 2019 IBM Corporation

151
Agile Training Module

Use short sprints

• It is not wise to coin a big project and hand it to offshore team in

expectation of results after 6 months
• Short iterations insure that you see what the offshore team is doing on
a regular basis. You can give quick feedback and redirect the team
quickly

ScrumMaster at both locations

• Most impediments will need to be worked within the context and

environment of each sub-team

Execute 3 to 4 sprints with entire team at local site

• When project starts it is wise to have offshore team travel to customer

site and work together with onshore team
• It takes 3 to 4 sprints of 2 weeks each at-least to build relations
• Use this to have discussions and formalize Norming and Chartering
together and also doing sprint zero activities together like setting up
frameworks, initial architecture & design etc.
• Offshore team will get to build relation directly with client and get to
hear requirements directly.

Involve full team in release planning, iteration planning, review, and

retrospectives

• Everyone on the team participates in the sprint planning meetings,

sprint reviews with your customer, and retrospectives
• If sub-team do their own retrospective, then share results with other
teams.

© 2019 IBM Corporation

152
Agile Training Module

Go for features teams over component or layer teams

• This would reduce integration time, improves quality, team morale and
builds knowledge redundancy

9.3 Agile Environments & Tools

Agile Environments:

An agile environment is defined as an environment that creates and

supports a culture that encourages a team of people to work toward a
common goal. This is done by incorporating the importance and value of
individuals and their interactions - especially in terms of working to
achieve quality, collaboration, and acceptance of frequent change in the
company culture.

The 10 Characteristics of an Agile Environment

1. Leadership is first and foremost about purpose

2. Business value is delivered by small, co-located, cross-functional
and self-organizing teams
3. Team membership is stable over a longer period to increase
performance
4. Management empowers decentralized decision-making
5. Temporary documentation is replaced with face-to-face interaction
6. Full transparency instills trust
7. Big projects are delivered as a series of small independent projects
all adding value
8. Frequent deliveries means short feedback loops which lead to higher
quality and engagement
9. Relationships and results brings joy of work (and happier people
produce more!)

© 2019 IBM Corporation

153
Agile Training Module

10. Make continuous improvement a natural part of the company culture

(failure needs to be an option)

The 7 Steps to Create an Agile Environment

To create such an Agile environment the organization should:

1. Shift to an integrative and interactive process

2. Set inspiring and meaningful goals
3. Empower self-organizing teams
4. Embed learning & development
5. Motivate via mastery, purpose and autonomy
6. Eliminate performance ratings
7. Accept leadership mandate

Don’t Forget the Cultural Shift

Chances are that by creating an Agile environment the culture of an

organization also shifts. This cultural shift is a combination of:

1. A shift of mindset
2. A shift of skills
3. A shift of behavior

By influencing the mindset, skills and behavior you can eventually

influence the culture as a whole.

© 2019 IBM Corporation

154
Agile Training Module

Agile Methodology Tools

The list shows some of the best tools on offer.

1. ActiveCollab: An affordable tool for small businesses, ActiveCollab is

easy to use. This software development aid requires little training and
provides excellent support.
2. Agilo for Scrum: Stakeholders get updated automatically on the
project’s progress with Agilo for Scrum. Features sprint reports and
burn down charts for better data mining.
3. Atlassian Jira + Agile: This powerful project management tool
facilitates development by incorporating Scrum, Kanban, and
customizable workflows.
4. Pivotal Tracker: This methodology tool is geared specifically for mobile
projects. A little jargon-heavy, it’s user-friendly after a brief orientation
period.
5. SprintGround: SprintGround was made with software developers in
mind — users can easily parse out projects, versions, and releases.
SprintGround also has a framework that encourages developers to look
at feature requests, suggestions, and questions in addition to offering
traditional bug tracking functionality.

© 2019 IBM Corporation

155
Agile Training Module

1. Active Collab

Active Collab is a great, affordable solution for small businesses. Because

it’s so easy to use, project managers don’t need to stress about teaching
their team how to use this celebrated software. Its powerful document
management, email-based communication features, priority and task
control, and budgeting features have made it particularly attractive for
project managers trying to manage multiple projects.

Pros: Intuitive, outstanding support, iOS apps, can bill the client straight
through the app, time tracking, and the ability to limit which user sees
what.

Cons: Timeline and column views for tasks instead of Gantt.

Cost: Self-hosted at $499; $49/month for up to 15 team members.

© 2019 IBM Corporation

156
Agile Training Module

2. Agilo for Scrum

If you have a project that needs a powerful communication tool, Agilo for
Scrum is one of your better bets. Agilo for Scrum automatically updates
stakeholders on the project’s progress. It also offers tools to make sure
that all team members are aware of the latest updates; every change
made by a user is automatically shown to their teammates by the
“Incoming Activity” panel. Additionally, Agilo offers a “Sprint Report” and
burn down charts for project managers looking to data mine their
progress.

Pros: A great communication system, responsive support team (24-hour

response time), and well-priced.

© 2019 IBM Corporation

157
Agile Training Module

Cons: No ability to host more than one project, no mobile app, and some
have noted that the system is difficult to learn.

Cost: €10 a month for unlimited users, one team, one project, or €20 for
unlimited users, unlimited teams, and 1 project.

3. Atlassian Jira + Agile

As one of the trusted brands in Agile software, Atlassian Jira + Agile is

quick to deliver a powerful project management tool that can fit most
offices. Teams can use this product as either a self-hosted or cloud-based
solution. Atlassian Jira + Agile offers Scrum, Kanban, and integrates with
JIRA, Confluence, and other Atlassian products. Project managers can
make customized workflows, visualize QA issues, and keep in constant
communication with “HipChat,” and the software offers a system called
“Release Hub” that makes sure your product is really “complete” when
it’s sent out to the final customer.

© 2019 IBM Corporation

158
Agile Training Module

Pros: Mobile app, strong backlog management, and lots of add-ons so

project managers can customize the software to their team’s needs.

Cons: There are so many features that Atlassian Jira + Agile has a strong
learning curve for new users and switching between apps can be a pain.

Cost: Starts at $10/mo for 10 users, scales up based on users.

4. Pivotal Tracker

Pivotal Labs, a consultancy on software development, created Pivotal

Tracker to specifically assist web and mobile developers. Pivotal Tracker
supports multiple projects, burndown charts, messaging between users,
project-based tasks, and user stories. Pivotal Tracker is relatively easy to
use, has a fantastic iOS app, and offers a nice set of feedback tools, so QA
is always at the forefront of the project.

© 2019 IBM Corporation

159
Agile Training Module

Pros: Great specifically for Agile software development, lots of

integrations (including Jira, Zendesk, and Bugzilla), supports cross-
functional teams, and free for individuals and public projects.

Cons: Support can be slow for non-paying users and the system is difficult
to customize.

Cost: Free for three users, 2GB of storage, and two private projects; also
free for public projects, non-profits, and academic institutions. Starts at
$12.50/month for five collaborators and goes up to $250/month for 50
collaborators.

5. SprintGround

SprintGround was made with software developers in mind — users can

easily parse out projects, versions, and releases. SprintGround also has a
framework that encourages developers to look at feature requests,
suggestions, and questions in addition to offering traditional bug tracking
functionality.

© 2019 IBM Corporation

160
Agile Training Module

Pros: Great for software development, encourages customer-driven

product development, and has many traditional Scrum functions like
burndown charts.

Cons: File storage is limited regardless of which plan you choose.

Cost: Free for three users, two projects, and 50MB of file storage. Starts at
€24 a month for eight users, unlimited projects, and 1GB of storage. At the
high end (for firms with more than 21 collaborators), SprintGround
charges €5 per user, per month.

9.4 Kanban Vs Scrum:

Kanban is all about visualizing your work, limiting work in progress, and
maximizing efficiency(or flow). Kanban teams focus on reducing the time it
takes to take a project(or user story) from start to finish. They do this by
using a Kanban board and continuously improving their flow of work.

Scrum teams commit to ship working software through set intervals called
sprints. Their goal is to create learning loops to quickly gather and
integrate customer feedback. Scrum teams adopt specific roles, create
special artifacts, and hold regular ceremonies to keep things moving
forward.

© 2019 IBM Corporation

161
Agile Training Module

Scrum Kanban
Regular fixed length sprints Continuous
Cadence
(i.e., 2 weeks) flow

Release
At the end of each sprint Continuous delivery
methodology

Product owner, scrum

Roles No required roles
master, development team

Lead time, cycle

Key metrics Velocity
time, WIP

Change Teams should not make Change can

philosophy changes during the sprint. happen at any time

3 Differences Between Scrum and Kanban

© 2019 IBM Corporation

162
Agile Training Module

How are Scrum and Kanban the same?

Both Scrum and Kanban allow for large and complex tasks to be broken
down and completed efficiently. Both place a high value on continual
improvement, optimization of the work and the process. And both share
the very similar focus on a highly visible work flow that keeps all team
members in the loop on WIP and what’s to come.

How are Scrum and Kanban different?

As alluded to above, there are a number of differences in both the
philosophy behind and the practical application of Scrum and Kanban.
While the individual differences are many, they can be grouped into the
following three buckets:

Scheduling, iteration, and cadence

Scrum processes place heavy emphasis on schedule. The scrum team is
provided with a prioritized list of story points that need to be completed to
deliver a shippable product. The team must decide how many of the points
they feel can be completed within one sprint. Anything outside the scope
they commit to must wait for the next sprint. Optimally, an efficient scrum
team will quickly learn their capabilities over the course of several sprints
and their estimates will improve and be optimized as time goes on. Then,
every two weeks (or however long their sprint is) the team produces a
shippable product, carries out a retrospective to discuss optimizing the
process, and moves into the next sprint. This iterative process is designed
to allow for accurate estimations of work flow and effective management
of multiple projects. On a Kanban team, there are no required time boxes
or iterations. While the Kanban method is iterative in nature, the continual
improvement is expected to occur in an evolutionary fashion as work is
continually completed. The limitations placed on various conditions in the
work flow will be regulated early in a team’s (or organization’s) use of

© 2019 IBM Corporation

163
Agile Training Module

Kanban until an optimal set of limits is arrived at to keep the flow steady
and efficient.

Roles and responsibilities

On scrum teams, there are at least three roles that must be assigned in
order to effectively process the work. The Product Owner, Scrum Master,
and Team Members. Each role has its own set of responsibilities, and they
must work together to achieve an orderly and efficient balance. The scrum
team itself also must be cross-functional, which is to say that one team
must have all the resources necessary to complete the entire sprint’s
work. Under Kanban, no set roles are prescribed. Practically speaking, it
makes sense for someone to serve as a project manager or supervisor,
especially for larger more complex Kanban projects, but the roles should
theoretically evolve with the needs of the project and the organization. A
Kanban team is not required to be cross-functional since the Kanban work
flow is intended to be used by any and all teams involved in the project.
Therefore, a team of specialists and a separate team of generalists may be
working on different aspects of the same Kanban project from the same
board, and that’s ok.

9.5 Xtreme Programming Vs Scrum:

Differences Between Scrum and Extreme Programming :
Scrum and Extreme Programming (XP) are definitely very aligned. In fact,
if you walked in on a team doing one of these processes you might have
hard time quickly deciding whether you had walked in on a Scrum team or
an XP team. The differences are often quite subtle, but they are important.
The table depicts the high-level difference:

Scrum Extreme
Work in iterations (called Work in iterations that are one or
sprints) that are from two two weeks long.
weeks to one month long.

© 2019 IBM Corporation

164
Agile Training Module

Do not allow changes into More amenable to change within

their sprints. Once sprint their iterations. As long as the
meeting is completed and team hasn’t started work on a
a commitment made to particular feature, a new feature
delivering a set of productof equivalent size can be swapped
backlog items. into the XP team’s iteration in
exchange for the unstarted
feature.
Scrum doesn’t prescribe XP does prescribe any
any engineering practices. engineering practices.

Test Your Knowledge

1. According to Scrum guidelines, who is responsible for hiring or
assigning a new person into a Dev Team?
a) Product Owner
b) Scrum Master
c) The self-managing Dev Team
d) This is outside of the scope of Scrum

2. Scrum does not focus on_________.

a) Delivering value to Customer
b) Simplicity-Maximizing the amount of work not done
c) Dev Team Management
d) Self- Organizing Dev Team
3. Team roles are defined in KANBAN.
a) True
b) False
4. XP does prescribe any engineering practices.
a) True
b) False

© 2019 IBM Corporation

165
Agile Training Module

5. SAFe recommend a Program Increment duration should be

a) 3 weeks
b) 6 weeks.
c) 8 to 12 Weeks
d) 12 weeks.

1. Case Study – I (IT Related)

Modernize eLearning Platform for University of ABZ

The University of ABZ has undertaken a large program to modernize their

Learning Platform for Students and Faculty. The platform should have
cognitive ability to easily search the courses and provide the
personalized dashboard for all learnings. The users can impart or
undertake the trainings based on their skill goals. An estimated time of
2 months was provided for the initiative. It was suggested by the
University Management that this initiative to be run in an Agile model so
that risks can be mitigated early and complete visibility is established at
all levels.

2. Case Study – II (IT Related)

Blockchain solving fraudulent academic qualifications

© 2019 IBM Corporation

166
Agile Training Module

The fraudulent academic qualifications by job seekers is a pain point of

recruitment firms globally. Therefore University of CBA is leading the
consortium of other Academic institutions to record and secure
academic credentials using digital ledger using a unique hash code. This
Blockchain initiative is estimated to be completed in Agile delivery model
within 4 months after arriving at the high-level understanding by the
consortia.

3. Case Study – III (Non IT Related)

Hosting Worldwide Artificial Intelligence Conference at the
Premium Institute of Delhi

The Premium Institute of Delhi is going to host the Worldwide

conference to push initiatives using Artificial Intelligence during this
December. Since this is going to be the mega event of all conferences that
attracts the Students, Research Scholars across the globe, the high-level
committee is looking after to conduct the activities associated with the
hosting in Agile mode. Abstracts are invited from the potential presenters
for AI, Cloud, Data and Blockchain tracks.

© 2019 IBM Corporation

167
Agile Training Module

Answer Keys

Chapter Name Question Number -Answer Keys

What is a project 1-d; 2-a; 3-c; 4-c; 5-a
Project Execution Methodologies 1-a; 2-a; 3-a; 4-b; 5-e
Agile Deep Dive 1-c; 2-d; 3-b; 4-b; 5-a
Scrum – Deep Dive 1-a; 2-b; 3-c; 4-a; 5-c
Scrum Artifacts 1-c; 2-a; 3-b; 4-d
Scrum Ceremonies 1-a; 2-d; 3-b; 4-c; 5-b
Scrum Sprint Planning 1-c; 2-d; 3-a; 4-b; 5-a
Scrum Metrics 1-c; 2-a; 3-b; 4-c; 5-b
Additional Info 1-d; 2-c; 3-b; 4-a; 5-c

© 2019 IBM Corporation

168
Agile Training Module

NOTICES
This material is meant for IBM Academic Initiative use only. NOT FOR RESALE.

TRADEMARKS

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of the
International Business machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies. A
current list of IBM trademarks in available on the web at “Copyright and trademark
information” at www.ibm.com/legal/copytrade.html.

Adobe, and the Adobe logo are either registered trademarks or trademarks of Adobe
Systems Incorporated in the United States, and/or other countries.

Microsoft, Windows and the Windows logo are trademarks of Microsoft Corporation in
the United States, other countries or both.

© Copyright International Business Machines Corporation 2019.

This document may not be reproduced in whole or in part without prior permission of
IBM.

US Government Users Restricted Rights – Use, duplication, or disclosure restricted by

GSA ADP Schedule Contract with IBM Corp.

© 2019 IBM Corporation

169