PMI-ACP course: Hands-on Exercises/Cases/Activities

1. Activity-1: Iterative; Incremental Development

When to run this activity:
In the first half of the course, whenever you feel it is appropriate. You may want
to run it right at the beginning (to drive home the basics of Agile) or just after
Slide-23 of Lesson-2 (after you have introduced the definition of Agility, Agile
manifesto and principles)
Purpose:
-

To get people energized and engaged pretty early in the program

To drive home the point about Agile being incremental and iterative
development
To drive home the point about delivering value early, each person working
collaboratively with others to achieve this

Material/Participants needed:
You will need 20 coins, 6 watches (anything that will measure time with 1 second
accuracy) and at least 10 active participants.
How to run the activity:
Seat 5 people around a table. Assign 4 of them as workers for department 1
through 4. The last person sitting at the table is the customer. The other five
people will stand behind one of the people seated at the table. The people
standing behind the workers are the department managers. The person standing
behind the customer is the company president. All of the people standing have
stopwatches as well as the customer. Place the 20 coins heads up in front of
department 1.

Ask the team to imagine they are working on a process, which requires 4
departments to do some work before the value is created for the customer. The
work is to turn over the 20 coins (from head to tail or the other way around). The
managers are not supposed to participate in the work they will simply keep
track of how much time it takes the worker in their department to do this work.
You will run the exercise 6 times. The first pass starts with the worker in
department 1 turning over each coin in front of them with one hand from heads to
tails. As soon as the worker starts, the manager for department 1 starts his
stopwatch as do the customer and the president.
When all the coins have been turned over to tails, worker 1 will slide over all 20
coins to the worker in department 2 next to them. When the first coin is moved to
worker 2, manager 2 will start their stopwatch. When the last coin is moved from
worker 1 to worker 2, manager 1 will stop their stopwatch. This process will be
repeated for worker 2, worker 3, and worker 4.
When the first coin is moved to the customer from worker 4, the customer will
stop their stopwatch (this is when the customer started realizing the value).
When the last coin is moved to the customer from worker 4, the president will
stop their stopwatch (this is when the total value was delivered).
Record the results of the first pass in a table like the one below:

In the second pass, repeat the exercise so that people get used to what they
need to do. Hopefully the timings will improve (be less) than the first pass.
For the third pass, reduce the batch size to 10. This means that worker-1 will turn
over 10 coins and then pass over those 10 coins to worker-2, before starting on
the remaining 10 coins. Similarly, worker-2 will finish work in batches of 10. As
before, the customer will stop their watch when they receive the first coin from
worker-4 and the President will stop their watch when all the coins have been
delivered to the customer. The managers will continue to track the amount of
time it takes for their worker to turn over all the 20 coins and pass them over to
the following department (or customer, in case of department-4).
Then have 3 more passes, reducing the batch size to 5, 2 and 1 respectively.
The results should look somewhat like the table below.

Batch
size
20
20
10
5
2
1

Dept-1

Dept-2

Dept-3

Dept-4

22
18
20
21
22
24

24
19
21
20
22
25

21
19
20
22
23
24

18
17
17
19
21
22

Customer President
93
82
47
23
13
14

102
95
64
34
22
24

This chart shows each departments productivity, the time to market (the first
penny to the customer), and project completion (the last penny to the customer).
De-brief instructions:
Ask the participants what their observations are. Some of the points that may
come up are as follows.
-

As batch size reduced, the customer saw value earlier (the overall cycle
time also reduced). Ask them what the reasons for this are parallel
working, early involvement of all departments, etc.
As batch size reduced, each departments productivity seems to have
worsened. So each department effectively sacrificed their productivity in
order to gain overall productivity. Ask the reasons why departments
productivity went down overhead of hand-offs, need for collaboration
with others, etc.
As batch size reduced, the need to work in close collaboration with other
departments increased.

Variations:
-

If there are less than 10 participants, have fewer departments (though

fewer than 3 departments probably takes the effectiveness away).
If there are more participants, ask the other participants to observe and
play the role of QA. To ensure that they dont switch off during this period,
tell them they need to share observations later.

2. Activity-2: Affinity Estimating

When to run this activity:
After covering the estimation topic and affinity estimation technique (Slide-27,
Lesson-4)
Purpose:
The purpose is to drive home the principles of estimation in Agile. It illustrates
how we can arrive at reasonably accurate estimates with low effort and
encourage the participation of the team members in the estimation process.
Material/Participants needed:
You will need a sample product backlog. Sample is given below, but you can use
any backlog that you are in a position to explain.
How to run the activity:
Give the team a product backlog comprising 15-20 stories to estimate. A sample
is given below, but you can use your own if you like. The idea is to have stories
that the team can understand fairly easily without requiring deep domain
knowledge and for you (as the product owner) to explain to the team.
Sample Product Backlog: OGC is a leader is creating online games and is commissioned with a
new game project that will be released in time for summer holidays. In this project, you have
decided to implement Agile methodologies. You have asked the customer to list the deliverables.
You are researching online and have asked your marketing division to collect information about
important features and ideas for this game. You have a release planned for early June.
Product Backlog:
Story
Develop story line and theme
Create basic animation and graphics

Set up difficulty levels and parameters

Create XML metadata for plugging into portal
Finalize graphics and background
Provide keyboard and mouse support
Implement access controls
XML/Database design for storing scores and levels information
Integrate into main portal
Read cache to suggest level and provide past scores
Auto-promote to next level
Implement beta feedback
Provide hooks for advertisements
Implement charging based on portal policies
Implement feedback from the field

You play the role of the Product owner and explain the stories to the team (not
more than 5-10 minutes). Then let the team estimate using Affinity estimation
technique. It should work as follows.
1. Put one story on one post-it note.
2. Draw a line on the whiteboard labeled Smallest at one end and Largest
at the other.
3. Ask the participants to put the stories in order of size. At this point, we are
basically comparing the stories against each other not talking in absolutes.
They should do this activity collectively.
4. Once they have finished putting stories in order of size, introduce
buckets labeled Extra Small, Small, Medium. Large and Extra
Large.
5. Now ask the team to put the stories into one of these buckets after
discussion. For example, the stories towards the Smallest end of the line
might go into Extra small or Small, etc.
De-brief instructions:

Ask the participants how they felt estimating in relative terms instead of
absolutes.
Ask them if they were able to resolve differences amicably and some of
the things they did (or might have done) to make the process smoother.
Ask them if they felt involved in the process.
Ask them if they think it can be applied in real life why or why not?

Variations:
You might try some of these variations.
-

Assign specific roles to the team: Product Owner, Scrum Master,

Developer, QA (especially if there is a cross-functional group).
Try to get them to do step-3 using mute mapping, i.e. do not allow them
to talk while they are re-ordering the items.
If the group is too large, split them up into smaller teams, each working
independently (ideally no more than 10 per team).

3. Activity-3: Prioritization using Relative weighting

When to run this activity:
After covering the topic about value-based prioritization (Slide-28, Lesson-9)
Purpose:
The purpose is to drive home how you can use this simple technique to assign
numeric scores for various parameters in order to get priorities in a relatively
easy manner and mostly free from biases and prejudices.
Material/Participants needed:
You will need a sample product backlog which is to be prioritized. Sample is
given below, but you can use any backlog that you are in a position to explain.
How to run the activity:
Give the team a product backlog comprising 15-20 stories to estimate. A sample
is given below, but you can use your own if you like. The idea is to have stories
that the team can understand fairly easily without requiring deep domain
knowledge and for you (as the product owner) to explain to the team.
Sample Product Backlog: ABC bazaar is an online store that has just had a successful initial
launch. The USP of the store is its simplicity, trendiness and stock of items that are chosen to
appeal to the newer generation, which is more likely to make purchase online. Because it is an

online store, releases are frequent and turnaround of the features is expected to be rapid. The
team uses Agile methodologies to deliver the features. There are a number of features being
considered for inclusion in the next release and you are discussing the prioritization with the
Product owner.
Product Backlog:
Story

Design a fast check-out process allowing a customer to place order with maximum 3 screens
System to support at least 100 concurrent users
Payment gateway option to include American Express (Visa and Mastercard already supported)
Logic to suggest related products for adding to the shopping card (e.g. camera case for camera
purchases)
Implement parameterized discounting policies to offer special promotions on specific occasions
Customer support options to include a "live chat" window to provide immediate online assistance

You play the role of the Product owner and explain the stories to the team (not
more than 5-10 minutes). Then let the team estimate using relative weighting
technique.
1. Put the stories in a tabular format and add the information to the stories as
we discuss each story.
2. For each story, ask the team to assign a score that denotes the benefit
of the story, i.e. how much it will benefit the customer. 1 being the lowest
and 10 is the highest.
3. For each story, ask the team to assign a score that denotes the penalty
of NOT having the story, i.e. how much the ABSENCE of the story will
impact the customer. 1 being the lowest and 10 is the highest.
4. Now calculate the total value score for each story that is the sum of the
benefit score and the penalty score.
5. For each story, ask the team to assign a score that denotes the cost of
the story, i.e. how much it will cost to build. The absolute cost is not
important, just a relative ranking on a scale of 10, 1 being lowest and 10
being the highest.
6. For each story, ask the team to assign a score that denotes the risk of
adding the story, i.e. how much risk is added by introducing the story. 1
being the lowest and 10 is the highest.
7. Now calculate a numeric priority as Total value score/(Cost score + Risk
score). Higher the priority score, higher the priority of the story. You could

also convert the priorities to ranks, Rank-1 being assigned to the story
with the highest priority and so on.
At this point, you should have a table that looks like this (the scores could vary of
course based on the teams decisions on the scores).

Requirement
Design a fast check-out process
allowing a customer to place order
with maximum 3 screens
System to support at least 100
concurrent users
Payment gateway option to include
American Express (Visa and
Mastercard already supported)

Benefit

Logic to suggest related products for

adding to the shopping card (e.g.
camera case for camera purchases)
Implement parameterized discounting
policies to offer special promotions on
specific occasions
Customer support options to include a
"live chat" window to provide
immediate online assistance

Penalty

Total
Value

Cost

Risk

Priority

0.58

0.70

1.25

11

1.83

1.00

1.67

De-brief instructions:
-

Ask the participants if the priorities arrived at with this method matched
with their gut feel priorities were there any surprises?
Ask them if they found value in the numeric scoring method?
Ask them if they think it can be applied in real life why or why not?

Variations:
You might try some of these variations.
-

Rank

Instead of you playing the Product owner role, assign a member of the
team to be the product owner.
If the group is too large, split them up into smaller teams, each running
their own prioritization exercise (no more than 10 members per team).

4. Activity-4: Simulating iterations

When to run this activity:

Near the end of the program probably after Lesson-12 or even after Lesson-13.
Purpose:
The purpose is to drive home the simple essentials of doing iterative
development, with selforganized teams. This simple simulation will bring
forward many of the ideas that make Agile very powerful.
Material/Participants needed:
A ball (soft, light should not hurt peoples fingers as they try to catch it). It works
wonderfully with larger groups, but at least 10 are needed to make this fun and
meaningful.
How to run the activity:
In order to play the Ball Point game, youll need a large open space with enough
room for everyone to stand. Youll also need about a brightly colored tennis ball
and you may want a whiteboard to do the debriefing. We play the game in the
following way:
1. Provide an overview of the game and the rules.
Everyone is part of one big team.
Each time the ball is passed, it must have air-time.
The ball must be touched at least once by every team member for the
run to complete.
Balls cannot be passed to your direct neighbor (immediate left or
immediate right).
The ball must return to the same person who introduced it into the
system.
If the ball is dropped before it completes the round, it goes back to the
start and the run starts again.
There are a total of five iterations.
2. Allow the team two minutes of preparation time to determine how they will
organize themselves.
3. Get an estimate from the team of how many times they can pass the ball
through the system.
4. Run two-minute iteration.
5. Allow the team one minute to discuss how to improve the process
(retrospective).
6. Repeat for five iterations. Make the fifth iteration a challenge. If you need
to, make up some ridiculous statistic such as the world record for a 12
person team is 10 rounds per minute!

In order to fully optimize the process, the team needs to rearrange and
reorganize. Hopefully they will do well and realize the power of learning as they
are working imbibing the spirit of Agile.
De-brief instructions:
At the conclusion of the exercise, debrief for five to ten minutes. There are a
number of interesting points that are worth talking about.
-

Firstly, its worth mentioning the Deming Cycle.

It may be worth pointing out that every system has a natural velocity.

You may want to ask the team if they thought they would have reached
the final outcome had they not been challenged by the instructor.

Variations:
You might try some of these variations.
-

Assign a Scrum Master or Lead within the team to facilitate the meetings
(planning meeting and retrospectives). Observe how he/she performs the
role and ask the team for their feedback.
If it is becoming monotonous, change the rules in between iterations. For
example you may say each time the ball is dropped, the team gets a
negative point. Or each time they fail to meet their estimate, they get
negative points.