PMI-ACP® Certification

Training Course
(21 Contact Hours/PDUs)
Days Title
• About PMI & PMI-ACP Certification
• About Exam Content Outline
Day - 1
• Introduction to Agile Methodology
8 Hours
• Domain I — Agile Principles and Mindset
• Practice Questions
• Domain II - Value Driven Delivery
Day - 2 • Domain Ill - Stakeholders engagement
8 Hours • Domain IV —Team Performance
• Practice Questions
• Domain V — Adaptive Planning
• Domain VI — Problem detection and resolution
Day - 3
• Domain VII —Continuous Improvement (Product,
8 Hours
Process, People)
• Practice Questions
 Time: 09 AM – 05 PM

Break 1: 11:00 AM – 11:15 AM

Lunch Break: 01:00 PM – 02:00 PM

Break 2: 03:00 PM – 03:15 PM

About PMI®

4
 Project Management Institute
Project Management Institute (PMI®) is a
Worldwide organization which was
established in 1969
“PMI is one of the world's largest not-for-profit
membership associations for the project
management profession, with more than 1
Million credential holders in more than 185
countries”.
(PMI website)

5
 Project Management Institute
• PMI®’s headquarters is located near Philadelphia,
Pennsylvania, USA.
• Service centres
– New Delhi, India;
– Singapore; and
– Lelystad, Netherlands.
• Offices
– Beijing and Shenzhen, China;
– Brussels, Belgium;
– Bengaluru and Mumbai, India;
– Porto Alegre, Brazil;
– Montevideo,
– Uruguay; and
– Washington, D.C.

6
 PMI® > Membership
1. Individual Membership
✓ USD 129 + USD 10 for application
You can also take
2. Student Membership Chapter membership
Fee vary
✓ USD 32 + USD 10 for application

3. Retiree Membership
✓ USD 65

7
 PMI® > Membership Benefits

• Gain exclusive access to PMI® publications

• Gain access to PMI® Global standards
• Networking options
– With chapters and online communities of practice
– Leadership opportunities
– Volunteer opportunities.
• Discounts on certification exams and renewals
• Professional development

8
PMI® > Global Standards
Foundational Standards

9
 PMI® > Global Standards
Practice Standards and Frameworks

10
PMI® > Global Standards

PMI® Practice Guides

11
PMI® in Pakistan
Chapters in Pakistan PMI®

PMI®

PMI®
 PMI® in Pakistan

There are 3 chapters in Pakistan

▪ PMI® Karachi Chapter

▪ PMI® Lahore Chapter 160+ members

▪ PMI® Islamabad Chapter

14
 PMI® Lahore Chapter
www.pmilhr.org.pk

▪ Established in 2004

▪ Not-for-profit organization

▪ Chapter Membership is $20 per year

▪ Registered Education Provider (REP)

▪ Run by elected volunteers

▪ Board consists of President and 6 Directors

15
 Activities of PMI®Lahore Chapter

▪ PMP® certification course (35 PDUs)

▪ Seminars (2 PDU)
▪ Annual Symposium (one day 8 PDUs)
▪ Risk Management Certification course (30 PDUs)
▪ Agile Certification Course (21 PDUs)
▪ CAPM® Certification course (24 PDU)
www.pmilhr.org.pk

16
PMI-ACP® Certification
 PMI® > Certifications
Project Management Institute offers 8 Certifications
1. CAPM® – Certified Associate in Project Management
2. PMP® – Project Management Professional
3. PfMP® - Portfolio Management Professional
4. PgMP® – Program Management Professional
5. PMI-RMP® – Risk Management Professional
6. PMI-SP® – Scheduling Professional
7. PMI-PBA® - Professional in Business Analyses
8. PMI-ACP® – Agile Certified Professional Started 2010

18
19
 PMI-ACP® Certification
• Started in 2010
• Fastest growing certification
• Over 35,000 certified practitioners
• For Business Leaders, CIOs & IT Managers,
Product Managers
• For PMO Leaders, Project Managers and
Business Analysts

20
 PMI-ACP® Certification
Books to Consult
• PMI publications
– PMI Agile Certified Practitioners Handbook
– PMI Agile Certified Practitioners - Examination
Content Outline
• Other books
– PMI-ACP Exam Prep by Mike Griffiths
– Agile Practice Guide
– PMI-ACP Exam Prep QAs & Explanations by Tim Bagnall

21
Certification Handbook

Free download from pmi.org

22
 Certification
and eligibility

Application
Process

23
 PMI-ACP® Certification
▪ Education

▪ Experience

▪ 21 hours of Agile Management Education

▪ Pass the Exam

▪ Certificate, valid for 3 years

▪ Need 30 PDUs in 3 years to renew

24
Eligibility

25
Exam fee

26
 Questions

1-1/2 minutes per question

27
Application Process
Apply on line
Application remains open for 90 days

10 days for application review

If the application comes under audit

• Copy of degree
• Copy of training certificate
• Experience verification

Pay on-line

1 year to schedule exam

3 times during 1 year

28
 Critical Success Factors
• Create a study plan
• Study 30 – 40 hours
• Join a study group
• Read the book 3 times, at least
• Take the sample tests
• Exam is not easy
• If you don’t study, you will fail

29
30
 How to maintain your PMI-ACP® Certification

You need 30 PDUs (Professional Developing Units)

over 3 years to renew your certification. You can get PDUs by:

▪ Cat A: Attending seminars/webinars (1 PDU for 1 hour of attendance)

▪ Cat B: Attending academic courses in PM (1 PDU=1 hr of attendance)
▪ Cat C: Self learning (1PDU=1 hour of learning)
▪ Cat D: Creating PM knowledge: Lectures, seminars, writing books/papers
(PDU according to time taken for preparation + lecture time)
▪ Cat E: Volunteer work (1 PDUs = 1 hour spent )
▪ Cat F: Working in Project Management Profession (5 PDUs per yr)

31
Exam Content Outline

32
Examination content outline

Free download from pmi.org

33
Examination content

34
Examination content

35
Domains, Sub Domains, and Tasks
Domains > Sub-Domains >Tasks

Domains

Sub-Domains

Tasks

37
 Domains and Tasks for PMI-ACP®
Agile project practitioners engage in a number of tasks. These 62 tasks
have been divided into seven domains:
Domain I: Agile Principles and Mindset (9 Tasks)

Domain II: Value-Driven Delivery (4 sub-domains, 14 Tasks)

Domain III: Stakeholders Engagement (3 sub-domains, 9 Tasks)

Domain IV: Team Performance (3 sub-domains, 9 Tasks)

Domain V: Adaptive Planning (3 sub-domains, 10 Tasks)

Domain VI: Problem Detection and Resolution (5 Tasks)

Domain VII: Continuous Improvement (6 Tasks)

38
 Domain I Domain II Domain III

Agile Principles Value Driven Stakeholders

and Mindset Delivery Engagement

Define Positive Stakeholders

9 Tasks Value Needs
3 Tasks 2 Tasks
Incremental Stakeholders
Development Involvement
5 Tasks 3 Tasks

Avoid Potential Stakeholders

Downsides Expectations
3 Tasks 4 Tasks

Prioritization
3 Tasks
9 tasks
14 tasks
39
Domain IV Domain V Domain VI Domain VII

Team Problem Detection, Continuous

Adaptive Planning
Performance Resolution Improvement

Team Formation Levels of Planning

3 Tasks 5 Tasks 6 Tasks
2 Tasks

Team Adaptation
Empowerment 2 Tasks
3 Tasks

Team
Agile Sizing &
Collaboration &
Estimation
Commitment
5 Tasks
4 Tasks

10 tasks
9 tasks
40
Tools & Techniques

41
Tools & Techniques

42
Tools & Techniques

43
 Knowledge & Skills
Each statement is preceded implicitly by Knowledge of or Skill in

• Agile values and principles

• Agile frameworks and terminology
• Agile methods and approaches
• Assessing and incorporating community md stakeholder values
• Stakeholder management
• Communication management
• Facilitation methods
• Knowledge sharing/ written communication
• Leadership
• Building agile teams
• Team motivation
• Physical and virtual co-location
• Global, cultural, and team diversity

44
 Knowledge & Skills
• Training, coaching, and mentoring
• Developmental mastery models (for example, Tuckman, Dreyfus, Shu Ha
Ri)
• Self-assessment tools and techniques
• participatory decision ( for example, convergent. shared collaboration)
• Principles of systems thinking (for example, complex adaptive, chaos)
• problem solving
• Incremental delivery
• Agile discovery
• Agile sizing and estimation
• Value based analysis and decomposition
• process analysis
• Continuous improvement
• Agile hybrid

45
 Knowledge & Skills
• Managing with agile KPIs
• Agile project chartering
• Agile contracting
• Agile project accounting principles
• Regulatory compliance
• PMI's Of Ethics and Professional Conduct

46
Questions/Answers
Introduction to Agile
Methodology

48
 Knowledge Revolution
Agriculture Industrial Knowledge
Revolution Revolution Revolution
17th-18th centuries 18th-20th Centuries Late 20th century ….

Focus on information
and collaboration
Planting Crops Development of
Herding animals machines and factories Emergence of
Knowledge workers,
People started living People started living in subject matter experts,
in one place cities taking part in analyses,
development and IT
related projects

49
Industrial Workers vs. Knowledge Workers
Characteristics of Industrial worker Characteristics Knowledge worker
• Work is visible • Work is invisible
• Work is stable • Work is changing
• Emphasis on running things • Emphasis is on changing things
• More structure with fewer decisions • Less structure with more decisions
• Focus on right answers • Focus on right questions
• Define the task • Understand the task
• Command and control • Give autonomy
• Follow the Standards • Continuous innovation
• Focus on quantity • Focus on quality
• Measure performance to standard • Continuously learn and teach
• Minimize cost of workers for a task • Treat workers as assets, not cost

50
Waterfall approach in handling
projects …

51
Waterfall …

Victoria Falls Zimbabwe

52
53
http://community.sysev.com/pmo-series-part-4/

54
Challenges faced by IT Projects using Waterfall approach

▪ 60% - 80% of IT related

project fail due to poor
requirements gathering,
analysis, & management
Failed ▪ 66% project failures due to
miscommunication
between business and IT
Challenged ▪ Cost of failed systems
Successful projects run into billions of
dollars.

55
 New methodology for IT Projects
• Need to have a new methodology for IT
related projects.
– Flexible approach to requirement
– Incremental development
– Involvement of Business function in Projects
– Fast deliverables

56
 Emergence of
Agile Methodologies

57
 Meaning of Agile…
• Quick and well coordinated in movement;
an agile leap
• Active, lively;
an agile person
• Marked by an ability to think quickly;
he is 75 and still very agile

58
http://community.sysev.com/pmo-series-part-4/

59
 Work is done in short
sprints or iterations

Working Software is
delivered at the end of
each sprint/iteration

Agile Method
http://community.sysev.com/pmo-series-part-4/

60
61
Improvement using Agile Methodologies

Failed

Failed

Challenged
Challenged
Successful
Successful

62
 Common Agile Misconceptions
• The Pizza Box Methodology (needs work)
• All-or-Nothing Thinking (can be mixed with
waterfall)
• Traditional Development Approaches are Dead
(Waterfall is still alive)

64
 Common Agile Misconceptions
• Just Do It Faster (may not be faster)

• Becoming Agile Only Impacts the Development

Organization (actually it impacts the whole organization)

• Agile is Just a Development Methodology (Can be used

for Project Management)

65
 Domain I
Agile Principles and Mindset

16 percent of exam i.e. 19 questions

66
 Domain I Domain II Domain III

Agile Principles Value Driven Stakeholders

and Mindset Delivery Engagement

Define Positive Stakeholders

9 Tasks Value Needs
3 Tasks 2 Tasks
Incremental Stakeholders
Development Involvement
5 Tasks 3 Tasks

Avoid Potential Stakeholders

Downsides Expectations
3 Tasks 4 Tasks

Prioritization
3 Tasks
9 tasks
14 tasks
67
 Domain I – Agile Principles and
Mindset
• Task 1:
– Advocate for agile principles by modeling those principles and
discussing agile values in order to develop a shared mindset
across the team as well as between the customer and the team.
• Task 2:
– Help ensure that everyone has a common understanding of the
values and principles of agile and a common knowledge around
the agile practices and terminology being used in order to work
effectively.
• Task 3:
– Support change at the system or organization level by educating
the organization and influencing processes, behaviors, and
people in order to make the organization more effective and
efficient.

68
 Domain I – Agile Principles and
Mindset
• Task 4
– Practice visualization by maintaining highly visible
information radiators showing real progress and real team
performance in order to enhance transparency and trust.
• Task 5:
– Contribute to a safe and trustful team environment by
allowing everyone to experiment and make mistakes so
that each can learn and continuously improve the way he
or she works.
• Task 6:
– Enhance creativity by experimenting with new techniques
and process ideas in order to discover more efficient and
effective ways of working.

69
 Domain I – Agile Principles and
Mindset
• Task 7:
– Encourage team members to share knowledge by collaborating
and working together in order to lower risks around knowledge
silos and reduce bottlenecks.
• Task 8:
– Encourage emergent leadership within the team by establishing
a safe and respectful environment in which new approaches can
be tried in order to make improvements and foster self-
organization and empowerment.
• Task 9:
– Practice servant leadership by supporting and encouraging
others in their endeavors so that they can perform at their
highest level and continue to improve.

70
Agile Manifesto

71
 Agile Manifesto
Agile manifesto came about as a result of a meeting
in Utah in February 2001. The meeting was attended
by 17 Agile Experts

1. Kent Black 10. Ron Jeffries

2. Mike Beedle 11. Jon Kern
3. Arie van Bennekum 12. Brian Marick
4. Alistair Cockburn 13. Robert C. Martin
5. Ward Cunningham 14. Steve Miller
6. Martin Fowler 15. Ken Schawber
7. James Grenning 16. Jeff Sutherland
8. Jim Highsmith 17. Dave Thomas
9. Andrew Hunt

http://www.agilemanifesto.org/

72
Agile Manifesto for Software Development

“We are uncovering better ways of developing

software by doing it and helping others to do it.
Through this work we have come to value:”

http://www.agilemanifesto.org/
73
 Agile Manifesto for Software Development

1. Individuals and interactions over process and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiations

4. Responding to change over following a plan

http://www.agilemanifesto.org/
74
 Agile Manifesto for Software Development

• Individuals and interactions over process and tools

– Projects are initiated by people

– Projects are done by people
– Projects are accepted by people
– Definition of ‘done’ is negotiated by people

http://www.agilemanifesto.org/ 75
 Agile Manifesto for Software Development

• Working software over comprehensive documentation

– Software projects are initiated to create valuable, high-quality

software
– Although documentation may be necessary for future
maintenance, but comprehensive documentation without
software is valueless
– Agile Manifesto emphasizes on working software over
comprehensive documentation

http://www.agilemanifesto.org/ 76
 Agile Manifesto for Software Development

• Customer Collaboration over contract negotiation

– Recognize at the start that things are going to change

– Requires flexible contracts
– Trusting relationship with customers

http://www.agilemanifesto.org/
77
 Agile Manifesto for Software Development

• Responding to Change over following a plan

– Initial plan may change in software development

– Develop flexibility in plan, so that it can be changed
– Change plans as requirement changes

http://www.agilemanifesto.org/
78
12 Guiding Principles
for Agile Manifesto

79
12 Guiding Principles for agile

81
 12 Guiding Principles for agile
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 preference to the shorter timescale.

4. Business people and developers must work together daily

throughout the project.

http://www.agilemanifesto.org/
82
 12 Guiding Principles for agile
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.

http://www.agilemanifesto.org/
83
 12 Guiding Principles for agile
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 teams reflect on how to become more

effective, then tunes and adjusts its behavior accordingly.

http://www.agilemanifesto.org/
84
 Declaration of Interdependence
In 2005 Agile Leadership Network (ALN) created a Declaration of
Interdependence for agile project management.
We are community of project leaders that are highly successful at
delivering results. To achieve these results:

1. We increase return on investment by making continuous flow of

value our focus.

2. We deliver reliable results by engaging customers in frequent

interactions and shared ownership.

3. We expect uncertainty and manage for it through iterations,

anticipation, and adaptation.

85
 Declaration of Interdependence
4. We unleash creativity and innovation by recognizing that individuals
are the ultimate source of value, and creating an environment where
they can make a difference.

5. We boost performance through group accountability for results and

shared responsibility for team effectiveness.

6. We improve effectiveness and reliability through situationally

specific strategies, processes and practices.

86
Agile Mindset

87
 Agile methods
Agile s/w Development
• Iterative & incremental development, where requirements
and solutions evolve through collaboration between self-
organizing & cross-functional teams.

Scrum – Subset of Agile

• Lightweight process framework for agile development.

88
Agile methods

89
 Agile is a Blanket Term for Many
Approaches
Is agile an approach, a method, a
practice, a technique, or a
framework?
Any or all of these terms could
apply depending on the situation.

Agile approaches and agile

methods are umbrella terms that
cover a variety of frameworks
and methods.

Lean & Kanban are named instances of lean thinking that

share lean concepts such as: “focus on value,” “small
batch sizes,” and “elimination of waste.”
90
 Strategy to Fulfil Agile Values &
Principles
• Adopt a formal agile approach, intentionally designed and
proven to achieve desired results.
– Then, Learn and understand the agile approaches before changing or
tailoring them.
– Premature and haphazard tailoring can minimize the effects of the
approach and thus limit benefits.
• Implement changes to project practices in a manner that fits
the project context to achieve progress on a core value or
principle.
– Use timeboxes to create features
– Divide one large project into several releases

91
 Agile methods
1. Scrum – lightweight model easy to understand
2. XP (Extreme Programing) – Software development model
3. Lean Software Development – Principles of development
4. Kanban Development – Visual board, limits WIP
5. Disciplined Agile Delivery - DAD
6. FDD (Features Driven Development) – Model based on
features
7. DSDM (Dynamic System Development Method) –
Includes feasibility and business in development model
8. Crystal – Clear, Yellow, Orange and Red

92
Some definitions used in Agile

93
Artifact – The output of a process or work, typically in the form of a
document, drawing, model, or code
Ceremony – Regular meeting of an agile project, such as iteration
planning meeting.
Chicken – Someone who is involved in the project but not
committed and should not be part of the core team
Done – Term used to define that a piece of work is complete. All
teams members should agree on the exact definition of done.
Grooming – Cleaning up the product backlog, by removing items,
refining items, or estimating items.
Ground rules/ Team Agreement – Unwritten rules that apply to all
team members.
Ideal time – Amount of time the assignment will take if there were
no interruptions.
Timebox - A previously agreed period of time during which a team
works steadily towards completion of some goal.
94
Information radiator – A group of artifacts that is used
communicate project status and other information
Metaphor – Substituting common name for a technical name,
so that non-technical stakeholders can understand
Osmotic communication – Communication that occurs as a
result of people sitting in an environment by over hearing
others.
Parking lot chart – Chart used for gathering requirements for
later discussion.
Persona – an imaginary person or identity created by the
team to model interactions with the system to gather
requirements
Pig – Someone on the project who is committed and is
impacted by the outcome.
95
Planning poker – a method of estimating size of a story.
Members are given cards with numbers and they show their
cards simultaneously to show the number of points they want
to give to a story.
Refactoring – Reorganizing the working code without having
an effect on the functionality or performance.
Smells – Symptoms of problems that effect the team
indicating that something is not right
Spike – A quick experiment used to help the team answer a
question and the path forward
Velocity – The number of features or user stories a team can
deliver in a fixed iteration.
War room – A location were the entire team can work in one
dedicated space.
96
Scrum Framework

97
 Meaning of ‘scrum’
scrum
• Noun
• an ordered formation of players, used to restart play in Rugby,
in which the forwards of a team form up with arms
interlocked and heads down, and push forward against a
similar group from the opposing side. The ball is thrown into
the scrum and the players try to gain possession of it by
kicking it backwards towards their own side.

98
Meaning of ‘scrum’

99
 Scrum
• Scrum is a Lightweight process framework for agile development.
• Easy to understand, designed to deliver working software in short sprints

• Has three roles, five ceremonies/events, and three artifacts

• Roles: Product Owner, Scrum Master, Team;

• Ceremonies/Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint
Retrospective & The Sprint
• Artifacts: Product Backlog, Sprint Backlog, Product Increment
• Activity: Product Backlog Refinement

100
 Pillars of Scrum
1. Transparency: Gives visibility to all stakeholder, of the outcome
– Vision Statement, Prioritized Backlog, Daily Scrum, Sprint Review, Burn Down Chart
2. Inspection: Checks to look for problems & deviations
3. Adaption: Adjusting processes to reduce future issues

Scrum prescribes four formal events for inspection and adaptation:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

101
 Scrum Roles
• Product owner – Responsible for managing the product
backlog.
• Scrum master – Servant leader to the development team.
Responsible for removing impediments to progress
• Team – Group of professional who build the product. The
team is empowered to mange its own work.

102
 Scrum Roles
PRODUCT OWNER
• Product owner decides what will be built and in which order i.e., grooms
the Product backlog
• Defines the features of the product or desired outcomes in form of
releases of the project and chooses release date of releases and content
for qualifying for being potentially shippable commodity after the release
• Ensures profitability (ROI) as being custodian for the customer and
prioritizes features according to market value and helps in finalizing
Minimally Marketable Functionality
• Adjusts initially and re-adjusts features, combination of features, releases,
etc. and their subsequent priority as and when needed
• Accepts or rejects work results during demo ceremony & Facilitates scrum
planning ceremony

103
Scrum Roles

104
 Scrum Roles
SCRUM MASTER
• Scrum Master is a facilitative team leader who ensures that the team
adheres to its chosen process & also ensures eradication of obstacles
• Ensures full functionality and productivity of team & Enables close
cooperation across all roles and functions; Shields the team from external
interferences
• Ensures that the process is followed, all ceremonies are appropriately
staged and conducted including issuing invitations to daily scrums, sprint
reviews/demo and sprint planning meetings
• Facilitates the daily scrums and scrum of scrums if there is big team
• Ensures open, candid and participative environment during retrospective
meeting to extract maximum benefit in form of process improvement and
the lessons learnt

105
Scrum Roles

106
 Scrum Roles
TEAM
• Team should be generalist i.e., cross-functional
• Team’s appropriate size is suggested to be seven plus or minus two
individuals; often splits the team if more than nine individuals and
conduct scrum of scrums
• Team is self organized and self motivated and it selects for its own
sprint goals and also specifies its work results
• Team generally does not pledges for velocity more than their
previous sprint & team should be innovative to look for all practical
options to achieve their goals within specified project guidelines
• Team demonstrates its work results to the product owner and then
goes for their internal retrospective along with the Scrum Master

107
Scrum Roles

108
Scrum Roles

109
 Scrum Ceremonies/Events

• The Sprint
• Sprint Planning
– Done to determine what is to be delivered in the scrum
• Daily scrum
• Sprint Review
• Sprint Retrospective

110
The Sprint – Time Boxed

111
 Scrum Ceremonies
SPRINT PLANNING
• Takes place at start of each sprint.
• Team meets with the product owner and discusses next stage of the
project by setting highest priority items from the product backlog
• The second part of the sprint planning meeting results in converting
this recently prioritized sprint backlog (by the consent of product
owner) into tasks with explicit estimate for each task and the
volunteer responsible persons
• Team also agrees with the product owner on the sprint goal
• The probable shippable deliverable commitment coming from the
team is generally based on the teams known velocity and their
precedence history

112
 Scrum Ceremonies
SPRINT REVIEW
• Takes place at the end of each sprint demonstrating functionality to
product owners and to those who are interested
• Team meet with the product owner and demonstrate the working
software produced during the recent sprint
• Gives opportunity to team and product owner to inspect and adapt the
product
RETROSPECTIVE
• Occurs at the closing stage of each sprint after demo
• Team now meets with its Scrum Master and looks retrospectively at what
went well and what went wrong in the previous sprint and what can be
improved and how it can be improved
• Individual actions are taken or assigned for futuristic improvement of the
process

113
 Scrum Ceremonies

DAILY SCRUM
• Team meets for a maximum of 15 minutes per day with the Scrum Master
around the team task board
• Team members update the task board
• Team also aligns itself with one another on tasks
• Team answers the following three questions
– What has the team member done in the last 24 hours?
– What will s/he be doing in the next 24 hours?
– What might be the probable obstacles for his recent activity?

114
 Scrum Artifacts
PRODUCT BACKLOG
• Prioritized by Product Owner and divided into Releases (grouping of
features which should go together as per business requirement and
customer’s suggestion)
• Product backlog should be appropriately Detailed, Estimable, Emergent &
Prioritized (DEEP)

SPRINT BACKLOG
• Stories that the team plans to take up in the upcoming sprint are placed
here

PRODUCT INCREMENT
• Sum of all PBIs completed during a Sprint, Must be in useable condition,
PO decides whether to release it, Meet the Scrum Team’s Definition of
Done
115
Scrum

116
Scrum flow diagram

117
 Scrum roles
Scrum Roles

118
 Scrum Ceremonies
Scrum
Ceremonies/Events

119
 Scrum Artifacts
Scrum Artifacts

120
 Step 1
Create backlog

20 features

121
 Step 2
Define
Sprint backlog

5 features
per sprint.
4 sprints 3 tasks
of 2 weeks. for
Total 8 weeks each
feature.
Total
15
tasks

20 features

122
 Step 3
The Sprint

5 features
per sprint.
4 sprints
of 2 weeks.
Total 8 weeks

15
tasks
2 weeks

20 features

123
 Step 4
5 features
Product shipment
per sprint.
4 sprints
of 2 weeks.
Total 8 weeks

15
tasks
2 weeks
Product
with 5
features

20 features

124
 5 features
per sprint.
4 sprints
of 2 weeks.
Total 8 weeks

15
tasks
2 weeks
Product
with 5
features

20 features

125
XP – Extreme Programing

126
 XP – Extreme Programing, Values
Extreme programming is a software development methodology which
is intended to improve software quality and responsiveness to
changing customer requirements.

1. Simplicity: what is the simplest thing that will work?

– Code and design for the need of today YAGNI
2. Communications:
– Ensure Project team knows what is expected of them, what others are
working on, Transfer knowledge from one team member to everyone
else on the team.
3. Feedback: Through constant feedback about their previous
efforts, teams can identify areas for improvement and revise their
practices. Failing fast can be useful.

127
 XP – Extreme Programing, Values
4. Courage: Refactoring, Deleting Obsolete
Code
– no matter how much effort was used to create.
– Developers work is entirely visible.
5. Respect: yourself by striving for higher
quality, others by not change the code that
will delay your peer code, or make his
feature stop working.
128
 XP – Extreme Programing, Activities
1. Listening:
2. Designing: Good design, changing one part of system will
not affect the other part.
– Create spike solutions to reduce risk.
– Re-factor whenever and wherever possible
3. Coding: can also be helpful to communicate thoughts for
programming problems
– Programmer finding it difficult to explain to explain solution
might code in simplifier manner and use the code for what is
meant.
– Other programmers can give feedback by including comments in
code as part of code review session.
4. Testing:
129
 XP – Extreme Programing, Roles
1. Coach – Mentor/ Guide/ Facilitator/
Communicator similar to the Scrum Master
2. Customer – The individual who provides
requirements priorities and direction for the
project similar to the Product Owner
3. Programmer – The developers who write the
code
4. Testers – Define and write the acceptability test

130
 XP – Extreme Programing
13 Core Practices
1. Whole team
2. The Planning Game
3. Small Releases
4. Customer Tests
5. Collective Code Ownership
6. Coding Standards
7. Sustainable Pace
8. Metaphor
9. Continuous Integration
10.Test driven development
11.Refactoring
12.Simple Design
13.Pair Programming

131
 XP – Rules
RULE # 1: WHOLE TEAM
• The practice is that the whole team sit together at one location.
• The team includes the customer/business representative who provides the
requirements.
• Customer Acts to “steer” the project
• Gives quick and continuous feedback to the development team

Advantages include
• Customer can give quick and knowledgeable answers to real development questions
• Customer makes sure that what is developed is what is needed
• Functionality is prioritized correctly
Disadvantages include
• Difficult to get an On-Site Customer
• The On-Site customer that is given may not be fully knowledgeable on requirements
• May not have authority to make many decisions
• Loss of work to the customer’s company
132
 XP – Rules
RULE # 2: THE PLANNING GAME

• Two functions: Release planning and Iteration Planning

• Uses stories are provided by the customer
• Technical persons determine schedules, estimates, costs, etc
• A result of collaboration between the customer and the developers

Advantages include
• Reduction in time wasted on useless features
• Greater customer appreciation of the cost of a feature
• Less guesswork in planning

Disadvantages include
• Customer availability
• Is planning this often necessary?

133
 XP – Rules
RULE # 3: SMALL RELEASES

• Small in terms of functionality

• Less functionality means releases happen more frequently
• Support the planning game

Advantages include
• Frequent feedback
• Tracking
• Reduce chance of overall project slippage

Disadvantages include
• Not easy for all projects
• Not needed for all projects
• Versioning issues

134
 XP – Rules
RULE # 4: CUSTOMER TESTS

• Customer describes functionality tests

• Developers builds tests as per the customer defined test

Advantages include
• Frequent that the software is working
• Reduce chance of overall project slippage

Disadvantages include
• Not all test may be possible
• May delay development if tests not defined well

135
 XP – Rules
RULE # 5: COLLECTIVE OWNERSHIP

• The idea that all developers own all of the code

• Enables refactoring

Advantages include
• Helps mitigate the loss of a team member leaving
• Promotes developers to take responsibility for the system as a whole rather then
parts of the system

Disadvantages include
• Loss of accountability
• Limitation to how much of a large system that an individual can practically ‘own’

136
 XP – Rules
RULE # 6: CODING STANDARDS

• All code should look the same

• It should not possible to determine who coded what based on the code itself

Advantages include
• Reduces the amount of time developers spend reformatting other peoples’ code
• Reduces the need for internal commenting
• Call for clear, unambiguous code

Disadvantages include
• Degrading the quality of inline documentation

137
 XP – Rules
RULE # 7: SUSTAINABLE PACE – THE 40 HOUR WEEK

• XP recognizes that high level of productivity can be achieved by team operating at

sustainable pace.
• The work week should be limited to 40 hours
• Regular overtime is a symptom of a problem and not a long term solution

Advantages include
• Most developers lose effectiveness past 40-Hours
• Value is placed on the developers well-being
• Management is forced to find real solutions

Disadvantages include
• The underlying principle is flawed
• 40-Hours is a magic number
• Some may like to work more than 40-Hours
138
 XP – Rules
RULE # 8: USE OF METAPHOR

• The oral architecture of the system

• A common set of terminology

Advantages include
• Encourages a common set of terms for the system
• Reduction of buzz words and jargon
• A quick and easy way to explain the system

Disadvantages include
• Often the metaphor is the system
• Another opportunity for miscommunication
• The system is often not well understood as a metaphor

139
 XP – Rules
RULE # 9: CONTINUOUS INTEGRATION

• New features and changes are worked into the system immediately
• Code is not worked on without being integrated for more than a day

Advantages include
• Reduces to lengthy process
• Enables the Small Releases practice

Disadvantages include
• The one day limit is not always practical
• Reduces the importance of a well-thought-out architecture

140
 XP – Rules
RULE # 10: TEST DRIVEN DEVELOPMENT

• Unit testing
• Test-first design
• All automated

Advantages include
• Unit testing promote testing completeness
• Test-first gives developers a goal
• Automation gives a suite of regression test

Disadvantages include
• Automated unit testing isn’t for everything
• Reliance on unit testing isn’t a good idea
• A test result is only as good as the test itself

141
 XP – Rules
RULE # 11: REFACTORING

• Changing how the system does something but not what is done
• Improves the quality of the system in some way

Advantages include
• Prompts developers to proactively improve the product as a whole
• Increases developer knowledge of the system

Disadvantages include
• Not everyone is capable of refactoring
• Refactoring may not always be appropriate
• Would upfront design eliminate refactoring?

142
 XP – Rules
RULE # 12: SIMPLE DESIGN

• Do as little as needed, nothing more

Advantages include
• Time is not wasted adding superfluous functionality
• Easier to understand what is going on
• Refactoring and collective ownership is made possible
• Helps keeps programmers on track

Disadvantages include
• What is “simple?”
• Simple isn’t always best

143
 XP – Rules
RULE # 13: PAIR PROGRAMMING
• Two Developers, One monitor, One Keyboard
• One “drives” and the other thinks
• Switch roles as needed
Advantages include
• Two heads are better than one
• Focus on work
• Two people are more likely to answer the following questions:
• Is this whole approach going to work?
• What are some test cases that may not work yet?
• Is there a way to simplify this?
Disadvantages include
• Many tasks really don’t require two programmers
• A hard sell to the customers
• Not for everyone

144
Feedback Loops

145
146
 Step 1
Release
Planning

147
 Step 2
Iteration
planning

148
 Step 3
Product
Development

149
 Step 4
Product
Shipment

150
 Feature-Driven Development (FDD)
Model based on features

Develop an Build by
Build a Plan by Design by
overall feature
feature list feature feature
model

PRACTICES FOR FDD

• Domain Object Modelling: To determine business requirements

• Develop by features: Breaking functions into two week chunks
• Individual code ownership: Code is owned by individuals (unlike XP)
• Feature teams: Small teams
• Inspections: Reviews to ensure good design
• Version Control/ Configuration management: Labelling code, tracking
changes, managing source code
• Regular builds: Ensure new code integrates with existing code
• Visibility of progress: Track progress
151
Feature-Driven Development (FDD)
• Jeff Deluka devised a feature naming template
– [Action] [Result] [Object]

• Helps agile project teams properly frame features for

development
• You can add words in between actions is the result of
something or object
– [Action] the [Result] by|for|of|to [Object]

– [Calculate] the [Total] of [a Debit Card Sale]

– [Calculate] [Total] [a Debit Card Sale] – Simple Version

152
Feature-Driven Development (FDD)
• You can ensure all the features that you are working on; that you
are delivering follow the feature naming template.
– [Determine] the [Credit Limit] of a [Customer paying with a Master
Card]

Translating Features into Code

• "Calculate the total of a sale"

– This implies an operation called calculatetotal() that will be used in a
class called Sale in code.
• "Retrieve the balance of bank account“
– It implies a balance account operation that will be using in the Class
ACCOUNT.

153
 Dynamic System Development Method
(DSDM-Atern)
• Dynamic System Development Method (DSDM) is used for software
development.
• DSDM fixes cost, quality and time at the outset and uses the MoSCoW
prioritization of scope into musts, should, could and would haves to adjust
the project deliverable to meet the stated time constraint.

• Focus on business needs

• Deliver on time
• Collaborate
• Never compromise on quality
• Build incrementally
• Develop iteratively
• Communicate continuously
• Demonstrate Control

154
Dynamic System Development Method
(DSDM-Atern)

155
 Crystal – S/w Development Method
• Color of crystal method depend on the team size and project criticality

• Size of project corresponds to a crystal color in terms of lightness or

darkness.
– Larger projects (Require Larger Project Team Members) that require more
coordination or communication
– map to progressively darker color from Clear to Yellow to Orange to Red to all
they way to Maroon.

• Criticality of the project; correspond to a crystal's hardness.

– Projects for systems that can cause more damage need added hardness in the
method, in terms of more validation and more verification rules.
– Ex: Quartz Crystal method low hardness is suited for a project where a few
developers are creating an inventor system.
– Same team controlling the creation and testing of artificial human heart valves
needs a diamond crystal method.

156
 Crystal – S/w Development Method
Combination of these two dimensions will guide your
team when selecting which specific crystal method is best
to implement on your project.
– Lighter Color and Lower Hardness are best for smaller and
less critical project.
– Darker Color and more hardness are best for larger and
more critical projects.

Characterized as
– Comfort (C), Discretionary Money (D), Essential Money (E)
and Life (L)
– Clear (1-6), Yellow (7-20), Orange (21-40), Red (41-80) and
Maroon (81-200)

157
 Crystal
Solutions are built
in increments
Size of team L100
depends of work to
be done
E20 E40 E100
Features

D6 D20 D40 D100

C6 C20 C40 C100

Clear Yellow Orange Red

1-6 7-20 21-40 41-100

Number of people involved
158
Lean Software Development

159
 Lean Software Development
• Lean software development is not an agile methodology,
however lean and agile principles are closely aligned.

• It is taken from Lean manufacturing approach and applied

to software development

• It is based on seven core principles

160
 Avoid partially done
work, delays,
Facilitate unnecessary features
communications for Eliminate
knowledge sharing Waste Let the team
make local
decisions
Amplify Empower
Learning the Team
Maximize ROI by
Decide as late as delivering
possible to pick valuable software
best user stories

Defer
LEAN
Deliver
Decision Fast

See how the system

aligns with the
Ensure quality during Optimize organization
the development
Build in
the
process Quality
whole

161
 Seven Wastes Of Lean
• Partially done work
• Extra processes
• Extra features
• Task switching
• Waiting
• Motion
• Defects

162
Kanban Development
(sign board)

163
 Kanban Development
(sign board)
• Kanban has been derived from lean production system in
Toyota. Kanban means ‘sign-board’ or ‘task-board’.
• Kanban limits the work in progress (WIP).
• Kanban is a method for managing knowledge work with an
emphasis on just-in-time delivery while not overloading the
team members.
• The process, from definition of a task to its delivery is
displayed for participants to see.
• Team members pull work from a queue.
• It is a visual process management system that tells what to
produce, when to produce it, and how much to produce.

164
 Kanban Core Values
1. Visualize the workflow
– Have some method for visualizing how the work is flowing
2. Limit WIP
– Keep the amount to work in progress low to increase visibility
3. Manage Flow of work
– Tracking work can identify issues
4. Make process policies explicit
– Ensure everybody understand the requirements of the process
5. Improve collaboratively
– Team should collectively own and improve the processes

165
 KANBAN BOARD

Work In
To Do Done
Progress
Stock Stock Data
search update base
Item Amend scheme
details order
Create
Order Process Order
list order

Order Log-in
refund

Kanban board is placed in the ‘war room’.

166
KANBAN BOARD

167
168
KANBAN BOARD

169
170
171
172
 Disciplined Agile
• Disciplined Agile (DA) is a process-decision
toolkit that provides straightforward guidance
to help people, teams, and organizations to
streamline their processes in a context-
sensitive manner.

173
 Disciplined Agile

Seven Principles of DA

174
 Disciplined Agile
High Level Delivery Life Cycle

175
 Disciplined Agile
Multiple Life Cycles supported by DA

176
 Disciplined Agile
The Agile Life Cycle

177
 Disciplined Agile
Scrum Roles

178
 Disciplined Agile
Primary Roles in DA

179
 Disciplined Agile
Secondary Roles in DA – for Scaling

180
Questions/Answers
Test
 Domain II
Value Driven Delivery

20 percent of exam i.e. 24 questions

Day 2

183
 Domain I Domain II Domain III

Agile Principles Value Driven Stakeholders

and Mindset Delivery Engagement

Define Positive Stakeholders

9 Tasks Value Needs
3 Tasks 2 Tasks
Incremental Stakeholders
Development Involvement
5 Tasks 3 Tasks

Avoid Potential Stakeholders

Downsides Expectations
3 Tasks 4 Tasks

Prioritization
3 Tasks
9 tasks
14 tasks
184
 Domain II - Value-Driven Delivery

What is value driven delivery?

• Projects are undertaken to generate business value.

• So, value-driven delivery should be the focus of the project

through out

• While making choices in project the focus should be on

options that generates business value.

185
 Domain II - Value-Driven Delivery
1. DEFINE POSITIVE VALUE - 3 TASKS
Task 1:
– Define deliverables by identifying units that can be produced
incrementally in order to maximize their value to stakeholders while
minimizing non-value added work.
Task 2:
– Refine requirements by gaining consensus on the acceptance criteria
for features on a just-in-time basis in order to deliver value.
Task 3:
– Select and tailor the team’s process based on project and organizational
characteristics as well as team experience in order to optimize value
delivery.

186
 Domain II - Value-Driven Delivery

2. AVIOD POTENTIAL DOWNSIDES - 3 TASKS

Task 4:
– Plan for small releasable increments by organizing requirements into
minimally marketable features/minimally viable products in order to allow
for the early recognition and delivery of value.
Task 5:
– Limit increment size and increase review frequency with appropriate
stakeholders in order to identify and respond to risks early on and at minimal
cost.
Task 6:
– Solicit customer and user feedback by reviewing increments often in order to
confirm and enhance business value.

187
 Domain II - Value-Driven Delivery
3. PRIOTORITZATION - 3 TASKS
Task 7:
Prioritize the units of work through collaboration with stakeholders in order to
optimize the value of the deliverables.
Task 8:
– Perform frequent review and maintenance of the work results by prioritizing
and maintaining internal quality in order to reduce the overall cost of
incremental development.
Task 9:
– Continuously identify and prioritize the environmental, operational, and
infrastructure factors in order to improve the quality and value of the
deliverables.

188
 Domain II - Value-Driven Delivery
4. INCREMENTAL DEVELOPMENT - 5 TASKS
Task 10:
– Conduct operational reviews and/or periodic checkpoints with stakeholders in
order to obtain feedback and corrections to the work in progress and planned
work.
Task 11:
– Balance development of deliverable units and risk reduction efforts by
incorporating both value producing and risk reducing work into the backlog in
order to maximize the total value proposition over time.
Task 12:
– Re-prioritize requirements periodically in order to reflect changes in the
environment and stakeholder needs or preferences in order to maximize the
value.
Task 13:
– Elicit and prioritize relevant non-functional requirements (such as operations and
security) by considering the environment in which the solution will be used in
order to minimize the probability of failure.
Task 14:
– Conduct frequent reviews of work products by performing inspections, reviews,
and/or testing in order to identify and incorporate improvements into the overall
process and product/service.
189
 Domain II - Value-Driven Delivery
This chapter has following 5 sections
Practice Tool/technique Knowledge/skill
Assessing value ➢ Return on Investment (ROI)
➢ Net Present Value (NPV)
➢ Internal rate of return (IRR)
Planning value ➢ Chartering ➢ Prioritization (L-1)
➢ Value stream mapping ➢ Agile contracting methods (L-3)
➢ Customer-valued prioritization
➢ Relative prioritization/ranking
➢ Product roadmap
➢ Risk-adjusted backlog
Delivering value ➢ Task/Kanban boards ➢ Incremental delivery (L-1)
➢ WIP limits
Confirming value ➢ Customer value prioritization ➢ Feedback through prototypes,
simulations, and
demonstrations (L-1)
Track and reporting value ➢ Earned value management
➢ Cumulative flow diagrams
➢ Risk burn down charts
➢ 190
Tasks/Kanban boards
Domain II - Value-Driven Delivery >
Assessing Value

191
 Domain II - Value-Driven Delivery >
Assessing Value

• Assessing Value of the project

– Methods used to determine if the business should
be undertaken or done.
– Three methods are used for this:

1. Return on Investment (ROI)

2. Net Present Value (NPV)
3. Internal Rate of Return (IRR)

192
 Domain II - Value-Driven Delivery >
Assessing Value
RETURN ON INVESTMENT (ROI) T&T

• ROI means what return the business receives after committing

investment on annual basis
• Higher ROI value is better for the business
• For example ROI of 70% is less attractive than ROI of 125%
• Formula for ROI is (Revenue - Cost) / Cost

Example:
– Establishing cost for 12 months 100,000
– Revenue at the end of 12 months 120,000
– ROI (120,000-100,000)/100,000
= 2/10x100= 20%

193
 Domain II - Value-Driven Delivery >
Assessing Value

PRESENT VALUE (PV) AND NET PRESENT VALUE (NPV) T&T

This method is used to determine the Prevent Value of the revenue of the future:
• PV means present worth of the project after taking inflation or interest into
account
Example:
If the revenue from a project after 12 month is 100,000. Due to 10%
inflation its present value will be 90,000.

• NPV means the cost of setting up the project is deducted from the present worth
of the project
Example:
If the revenue from a project after 12 month is 100,000. And 50,000 was
spent in setting up the business. Then the NPV will be:
(100,000-50,000) = 50,000. Due to 10% inflation its net present value will be
45,000.
In both cases higher PV and higher NPV will better for the project.
194
 Domain II - Value-Driven Delivery >
Assessing Value
T&T
INTERNAL RATE OF RETURN (IRR)

• The internal rate of return (IRR) is a rate of return used in capital

budgeting to measure and compare the profitability of investments.
• IRR tells us the rate of return the project will have over a given period of
time.
• It is also called the discounted cash flow rate of return. In the context of
savings and loans, the IRR is also called the effective interest rate. The
term internal refers to the fact that its calculation does not incorporate
environmental factors (e.g., the interest rate or inflation).
• IRR means expression of return on project in terms of interest rate
• Higher IRR is better for the project
• E.G. IRR of 10% is less attractive than IRR of 12.5%, for instance

195
Domain II - Value-Driven Delivery >
Planning Value

196
 Domain II - Value-Driven Delivery >
Planning Value
T&T
CHARTERING
• Chartering in Agile is similar to the Develop Project Charter in PMBOK.
• However the level of details and assumptions is different.
• Agile Charters can be lightweight worksheets or fairly detailed documents.

• Typically they should answer W5H questions

1. What is the project about? A high level description of the project.
2. Why is it being undertaken? Business rational and requirement
3. When will it start and end? Start and end dates
4. Who will be engaged? Project participants and stakeholders
5. Where will it be done? Work site, location
6. How will it be undertaken? Approach, agile methods to be used

197
 Domain II - Value-Driven Delivery >
Planning Value
T&T
VALUE STREAM MAPPING

• Value Stream Mapping is a lean manufacturing technique adopted by Agile

methods to reduce waste.
• It illustrates the flow of information required to complete the work.
• Involves creating visual maps of the process
• It is used to determine wastages in the process to improve efficiency
• Some example of wastes are:
• Queuing for elevator, rebooting computer after program crash, using
official stationery for drafts.

<diagram on next page>

198
 Domain II - Value-Driven Delivery >
Planning Value T&T
VALUE STREAM MAPPING

199
 Domain II - Value-Driven Delivery >
Planning Value
T&T
CUSTOMER VALUED PRIORITIZATION

Customer Valued Prioritization is a method of prioritizing features to be

included in releases. Some of the schemes that are used for prioritization
are:

• MoSCoW: Must have; Should have; Could have; Won’t have

• 100 point method: Stakeholders are given 100 points to distribute to various
features
• Kano Analyses: Clarify customer preference in 4 categories. Delighters, Satisfiers,
Dis-satisfiers, and Indifferent. Features are selected based on feedback.
• Requirement Prioritization Model: Stake Calculate priority of feature based on
benefit, penalty, cost, and risk.

200
 MoSCoW Prioritization
• All requirements are important but they are prioritized to deliver the
greatest and most immediate business benefits early. Developers will
initially try to deliver all the Must have, Should have and Could have
requirements but the Should and Could requirements will be the first to
be removed if the delivery timescale looks threatened.

• Must Have:
– These are requirements that are absolutely fundamental to the solution in
order to meet the business need, with out these, the solution will be
unworkable.
– They define the minimum usable subset that a project must have to guarantee
the delivery of a working solution as well as an overall project success.
– Requirements can be downgraded from Must have, by agreement with all
relevant stakeholders; for example, when new requirements are deemed
more important.

201
 MoSCoW Prioritization
• Should Have:
– Requirements labelled as Should have are important but not
necessary for delivery in the current delivery timebox.
– Should have requirements can be as important as Must have,
they are often not as time-critical or there may be another way
to satisfy the requirement
– can be held back until a future sprint.
• Could Have:
– These are the requirements that can be more easily left out of
the solution.
– These could improve user experience or customer satisfaction
for little development cost.
– These will typically be included if time and resources permit.

202
 MoSCoW Prioritization
• Won't Have:
– These are requirement that the project team has agreed; will not be delivered on the project
at all, are least-critical, lowest-payback items, or not appropriate at this time.
– Occasionally the term Would like to have is used; however, that usage is incorrect, as this last
priority is clearly stating something is outside the scope of delivery.

• Note:
– Gain consensus on the meaning of each of these terms
– must write them down and post them where every one can see them, and most importantly
follow these definitions consistently through out their specific projects.
– Just imagine; what happen if you change halfway through project the Must Have to Might
Have; it would be disaster.
– Highly recommended, no more than 60 % of the development effort is going to be spend on
Must Have,
• The remaining 40% effort is spent on Should Have and Could Have
• Any thing higher than 60% possess a significant risk to the success and the predictability of the project
unless the environment is well understood i.e. the team has been established for a reasonable amount
of time & the external risks are minimal.

203
 The Kano Model
• Kano Analysis designed to help categorize how to achieve customer
satisfaction and loyalty with in the product development process. Product
attributes are broken down in to following categories.

• Product Categories

• Basic Quality
• Performance Quality
• Attractive Quality

• Indifferent Quality
• Reverse Quality

• Illustrates how some features can contribute either positively or

negatively to the customer experience.

204
 The Kano Model
• Basic Quality
– This product quality attribute/ feature may also be refer as "Must-be"
or "Threshold" attribute.
– This attribute is typically taken for granted when it is provided but
when this type of attribute is not provided, It causes customer
dissatisfaction.
– Provides obvious features and those might be expected by customer.
– Basic or essential attribute does not improve customer experience by
being part of product.
• Example
– Cell Phone that can make a phone call, if it can't make a call the
customer would understandably be dissatisfied with the product.
– It's not necessary that customer would tell the company about this
when asked about a quality attribute. If this type of feature is
overlooked in the product development process then product is simply
incomplete & does not cover basic needs.

205
 The Kano Model
• Performance Quality
– This can differentiate your product and help it stand out from the
competition, also called "Satisfier" or "Linear" attribute.
– This product attribute result in customer satisfaction when it is
fulfilled, however when not provided the customer once again feel
sense of dissatisfaction.
– Unlike basic attribute customer explicitly demands this type of
attribute, and they use this type of attribute when choosing a product.
– Customer satisfaction increases proportionally as these features are
provided.
• Example:
– Cell Phone's Battery Life, the better this feature or attribute is
executed by the manufacturer the better the customer experience will
be with the phone

206
 The Kano Model
• Attractive Quality:
– This product quality attribute/ feature may also be refer as "Delighter" or
"Exciter" attribute.
– This type of attribute is unexpected from the customer's perspective.
– It provide satisfaction when you can achieve it fully but it does not really cause
dissatisfaction when it is not fulfilled.
– If asked the customer would not know how to describe or ask for such a
feature, because it is a new concept, a new innovation.
– This has the highest potential to lead to high profits because they exceed the
customer expectation.
– WOW Factor of a new product, and can be a huge differentiator for producers.
• Example:
– Camera, when mobile phone first came out with camera functionality the
feature was quite limited but still very attractive for buyers
– camera phone will differentiate them from normal phones and have an extra
wow factors because consumers did not expected to find in a telephone.

207
 The Kano Model
• Indifferent Qualities:
– do not result in customer satisfaction or dissatisfaction,
this type of product attribute is not good and not bad.
– The customer does not associate any value with this kind
of feature.
• Reverse Quality:
– attribute brings customer satisfaction when it is not
present in the product.
– in other words, if the feature or product attribute were not
in the product the customer would have a better overall
experience.
– This kind of feature is most often overly complicated.

208
 The Kano Model
• Note:
– Attribute can shift to different categories over time, a feature
that was once exciting to the customer may change over time
and become a liner feature and finally shift to become a
necessary requirement.
– This happens because customer grows a custom to product
feature and then comes to expect more out of product that they
purchase and use.
– Based on Kano model a well received product is one that include
basic, performance and exciter features.
– Indifferent Quality & Reverse Quality categories are less
common because product teams try to avoid these type of
product attributes or features.
• Additional features built into a product don't necessarily leads to
happier customers

209
 Domain II - Value-Driven Delivery >
Planning Value
T&T
RELATIVE PRIORITIZATION/RANKING
• Features are prioritized based on the business needs and the business
value of the feature.
• Relative prioritization provides a framework for deciding if and when to
incorporate changes.
• Question should be asked to the business: “What items are more
important?”

A
Minimum
B marketable release
C
D Cut off to meet
Budget/time

210
 Domain II - Value-Driven Delivery >
Planning Value
T&T
• Risk Value Prioritization Quadrant

211
 Domain II - Value-Driven Delivery >
Planning Value
T&T

PRODUCT ROADMAP

• Product roadmap is a visual overview of the product releases and

its main components.
• It is a communication tool that provide stakeholders with a quick
view of primary release points and intended functionality.
• It shows how the product will be developed and released

212
 Domain II - Value-Driven Delivery >
Planning Value
T&T

PRODUCT ROADMAP

• Think Big, Plan Small

• Product roadmap is a visual overview of the product releases and
its main components.
• It is a communication tool that provide stakeholders with a quick
view of primary release points and intended functionality.
• It shows how the product will be developed and released

213
 Domain II - Value-Driven Delivery >
Planning Value
T&T
PRODUCT ROADMAP

• Defines a strategic view of where the product is

headed over the mid to long term
• Tied to the organization’s vision, and strategic
goals, 12 months
• Provides guidance than a strict project plan
• Helps PO acquire funding
• Aligns Stakeholders and facilitates prioritization

214
 Domain II - Value-Driven Delivery >
Planning Value
T&T
PRODUCT ROADMAP

• Roadmap speaks in terms of epics and

themes
• Agile Product Backlog is the detailed features
and other tasks to deliver the product
•

215
 Domain II - Value-Driven Delivery >
Planning Value
T&T
PRODUCT ROADMAP - Question

“We’re agile, so why do we need a long-term

product roadmap?”

216
 Domain II - Value-Driven Delivery >
Planning Value
T&T
PRODUCT ROADMAP - Answer

“It’s Hard to Communicate Strategy in a

Backlog”

217
 Domain II - Value-Driven Delivery >
Planning Value
T&T

PRODUCT ROADMAP vs Product Backlog

218
 Domain II - Value-Driven Delivery >
Planning Value
T&T

Evolving PRODUCT ROADMAP

219
 Domain II - Value-Driven Delivery >
Planning Value
T&T
PRODUCT ROADMAP

220
 Domain II - Value-Driven Delivery >
Planning Value
T&T
Goal Oriented PRODUCT ROADMAP

221
 Domain II - Value-Driven Delivery >
Planning Value
T&T
Goal Oriented PRODUCT ROADMAP

222
 Domain II - Value-Driven Delivery >
Planning Value
RISK ADJUSTED BACKLOG T&T
• Risks are anti-value.
• They take time and resources away from the efforts that deliver value and
threaten the project benefits. So risk mitigation and avoidance should be done
early. Features that have higher risk score should be given lower priority. Create
spikes to work on risks. Adjust backlog to include risks.
Business Business
Plan risk feature feature
management Perform
Identify Risk Risk
qualitative
risks response response
analyses

Business Business
Perform feature feature
Monitor
and Control quantitative
Risks Plan risk analyses Business Selected
response feature

Risk
response
223
 Domain II - Value-Driven Delivery >
Planning Value
K&S
Level-3
AGILE CONTRACTING METHODS

• Contracting in Agile is different from the traditional methods.

• In traditional methods the Scope or functionality are fixed and time and
cost will be adjusted to complete the scope or functionality.
• In agile methodology resources and time are fixed and scope or
functionality is flexible.
• So the number of features to be done in an iteration will depend on the
time, recourses, and output of the team.

<diagram on next page>

224
 AGILE CONTRACTING METHODS
Inverted Triangle Model

Scope or
Functionality Resources Time

Fixed
Agile

Traditional
Variable

Time Cost Scope or

Functionality

225
 Domain II - Value-Driven Delivery >
Planning Value
K&S
Level-3
AGILE CONTRACTING METHODS
Example of contracts:

• Contracts used in Agile need to consider the aspect of flexibility of scope.

• Hybrid (Time and Material) type of contract could be suitable.
• Customized contract may be considered which have more flexibility to
suite requirement of project.

226
 Domain II - Value-Driven Delivery >
Planning Value
K&S
Level-3
AGILE CONTRACTING METHODS

227
Domain II - Value-Driven Delivery >
Delivering Value

228
 Domain II- Value-Driven Delivery >
Delivering Value
DELIVERING VALUE
• Goal is to deliver value throughout the Agile project by minimizing waste
and maximizing value. Examples:
Waste Description Example
Partially done work Work started but not Code waiting for testing
complete
Extra process Work that does not add value Unnecessary documentation
Extra features Features that are not Gold plating
required or ‘nice to have’ Technology features
Waiting Delays in reviews Waiting for prototype
reviews/approvals
Motion Efforts required to Distributed teams
communicate or move
information
Defects Defective software or Software bugs
documents
229
 Domain II - Value-Driven Delivery >
Delivering Value
TASK AND KANBAN BOARDS T&T

• Task and Kanban boards can help deliver value on agile projects. These
are simple low tech, high touch displays that provide basic information on
the progress. These can be used instead of Gantt Charts

Work In
To Do Done
Progress
Stock Stock Data
search update base
Item Amend scheme
details order
Create
Order Process Order
list order

Order Log-in
refund
230
 Domain II - Value-Driven Delivery >
Delivering Value
WIP LIMITS T&T

• Work in Progress (WIP) is the work that has been started but has not
been completed.
• Having more WIP is not good for the project as it increases waste.
• WIP consumes capital.
• WIP can also hide bottle necks in the processes and workflow
• Agile aims to limit the WIP.
• This is done through Kanban Boards.
• Limits of WIP is written in the WIP section of the board.

231
 Domain II - Value-Driven Delivery >
Delivering Value
WIP LIMITS T&T
WIP LIMIT

Work In
To Do Done
Progress (3)
Stock Stock Data
search update base
Item Amend scheme
details order
Create
Order Process Order
list order

Order Log-in
refund

232
 Domain II - Value-Driven Delivery >
Delivering Value
K&S
Level-1
INCREMENTAL DELIVERY
• Incremental delivery is a way to
optimize the delivery value on Higher
the project.
2
• Delivering feature for a release
in increments can help in testing
the functionality of the feature, Lower
which can help in making 1
changes if required.
• If the product is tested after
completing all features, then the
cost of change will be much
higher.

233
Domain II - Value-Driven Delivery >
Confirming Value

234
 Domain II - Value-Driven Delivery >
Confirming Value
T&T

CUSTOMER-VALUED PRIORITIZATION

• Customer-valued prioritization is used to confirm value of the product

that is being developed.
• This is done after each iteration.
• Together the team and the customer answer the questions: “Have things
changed?” and “Do we still want to move on the item ‘A’ in the next
iteration?”
• Any re-prioritization is done in the iteration planning session.

235
 Domain II - Value-Driven Delivery >
Confirming Value K&S
Level-1

FEEDBACK THROUGH PROTOTYPE, SIMULATIONS, AND DEMONSTRATION

• Demonstration of functionality are critical to confirming success on

software projects.
• Software is intangible and difficult to reference.
• In most of the cases the systems being built are new and will not be
repeated.
• The users should be able to see something to determine if the systems
meets the functionality requirements.
• Term I K I W I S I (I Know It When I See It) is often used in software
industry for getting feedback.

236
Domain II - Value-Driven Delivery >
Tracking and Reporting Value
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
TRACKING AND REPORTING VALUE

• Various methods are used to monitor the rate at which features and value
are being delivered to make sure that the project is on track.
• These methods include:

– Agile Earned Value Management

– Cumulative Flow diagrams
– Risk burn down graphs
– Task and Kanban Boards
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
AGILE EARNED VALUE MANAGEMENT

• In this method cumulate cost of the project is calculated and is plotted as

an S-curve.
• Actual cost is plotted to show the present cost of the projected.

• Planned Value – The authorized budget assigned to scheduled work.

• Actual Cost – The realized cost incurred for the work performed on an
activity during a specific time period.
• Earned Value – The measure of work performed expressed in terms of the
budget authorized for that work.
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
AGILE EARNED VALUE MANAGEMENT
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
AGILE EARNED VALUE MANAGEMENT
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value T&T

Concept Formula Result Interpretation

Schedule Variance SV = EV -PV < 0 is bad

(SV) = 0 is good
> 0 is good
Schedule Performance SPI = EV / PV < 1 is bad
Index (SPI) = 1 is good
> 1 is good
Cost Variance (CV) CV = EV -AC < 0 is bad
= 0 is good
> 0 is good
Cost Performance CPI = EV / AC < 1 is bad
Index (CPI) = 1 is good
> 1 is good
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
EARNED VALUE MANAGEMENT T&T

S-Curve Graph
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
EARNED VALUE MANAGEMENT T&T

S-Curve Graph
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
CUMULATIVE FLOW DIAGRAMS (CFD)

• Cumulative flow diagrams are tools for tracking and forecasting agile
projects
• CFDs can help us gain insight into project issues, cycle times, and likely
completion dates.
• Different sections of the diagrams can be used to identify potential issues.
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
CUMULATED FLOW DIAGRAMS (CFDs) T&T

Not started

Completed
Started
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
CUMULATED FLOW DIAGRAMS (CFDs) T&T
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
RISK BURNDOWN CHARTS

• Risk are anti-value as they waste time and produce not value
• High-risk activities should be into earlier iterations of the project and
incorporate mitigation actions into the backlog.
• Risk severity is determined as = Risk probability x Risk impact
• Risk and prioritized and response strategy developed
• Risk progress is tabulated on Risk Burn Down Graphs
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
RISK BURN DOWN CHARTS T&T
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
RISK BURN DOWN CHARTS

– Funds Shortage increases as the project progresses. Hence Severity of

this risk becomes more
– The risk severity of Visas of Offshore Resources not getting processed
on time decreases as the time progresses
– The Risk Severity of Availability of Database Architect goes down over
time
– The risk “Delivery of Servers on Time” increases over time since the
hardware vendor delays the delivery of Servers. As Project progresses,
if the vendor delays further then the severity becomes very high.
– Risk of Changing Requirements goes down over time since customer
gets clarity on requirement. Hence the risk severity also goes down
– As the projects progresses, the risk of Availability of Expert Developers
goes down and hence severity also goes down.
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
T&T
TASK BOARDS AND KANBAN BOARDS

• Tasks boards and Kanban boards are a very good visual tool for tracking
and reporting value of the project.
• As they are highly visible they can show how the work is progressing over
in the project.
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
TASK AND KANBAN BOARDS T&T
 Domain II - Value-Driven Delivery >
Tracking and Reporting Value
TASK AND KANBAN BOARDS T&T
Questions/Answers
Test
 Domain III
Stakeholders Engagement

256
 Domain I Domain II Domain III

Agile Principles Value Driven Stakeholders

and Mindset Delivery Engagement

Define Positive Stakeholders

9 Tasks Value Needs
3 Tasks 2 Tasks
Incremental Stakeholders
Development Involvement
5 Tasks 3 Tasks

Avoid Potential Stakeholders

Downsides Expectations
3 Tasks 4 Tasks

Prioritization
3 Tasks
9 tasks
14 tasks
257
Domain III - Stakeholders Engagement
Effective Communication and Stakeholders

258
 Domain III - Stakeholders Engagement

FOCUS ON STAKEHOLDERS

• Knowledge workers projects do not produce any tangible

products, therefore effective communication with
stakeholders is critical for the success of the project.
• Effective communication guides the team to keep the
stakeholder engaged.
• The stakeholder will also know what the team is working on
and if the product is as per the stakeholders’ expectations.

259
 Domain III - Stakeholders Engagement

UNDERSTAND STAKEHOLDERS NEEDS - 2 TASKS

Task 1:
– Identify and engage effective and empowered business stakeholder(s)
through periodic reviews in order to ensure that the team is knowledgeable
about stakeholders’ interests, needs, and expectations.
Task 2:
– Identify and engage all stakeholders (current and future) by promoting
knowledge sharing early and throughout the project to ensure the
unimpeded flow of information and value throughout the lifespan of the
project.

260
 Domain III - Stakeholders Engagement

ENSURE STAKEHOLDERS INVOLVEMENT - 3 TASKS

Task 3:
– Establish stakeholder relationships by forming a working agreement among
key stakeholders in order to promote participation and effective
collaboration.
Task 4:
– Maintain proper stakeholder involvement by continually assessing changes
in the project and organization in order to ensure that new stakeholders are
appropriately engaged.
Task 5:
– Establish collaborative behaviors among the members of the organization by
fostering group decision making and conflict resolution in order to improve
decision quality and reduce the time required to make decisions.

261
 Domain III - Stakeholders Engagement

MANAGE STAKEHOLDERS EXPECTATIONS - 4 TASKS

Task 6:
– Establish a shared vision of the various project increments (products,
deliverables, releases, iterations) by developing a high level vision and supporting
objectives in order to align stakeholders’ expectations and build trust.
Task 7:
– Establish and maintain a shared understanding of success criteria, deliverables,
and acceptable trade-offs by facilitating awareness among stakeholders in order
to align expectations and build trust.
Task 8:
– Provide transparency regarding work status by communicating team progress,
work quality, impediments, and risks in order to help the primary stakeholders
make informed decisions.
Task 9:
– Provide forecasts at a level of detail that balances the need for certainty and the
benefits of adaptability in order to allow stakeholders to plan effectively.

262
 Domain III - Stakeholders Engagement
This chapter has the following 4 sections:
Practice Tool/Technique Knowledge/Skill
Aligning ➢ Wireframes ➢ Incorporate stakeholder values (L-
Stakeholders ➢ Personas 1)
understanding ➢ User stories ➢ Stakeholder management (L-1)
➢ Story maps ➢ Vendor management (L-3)
Communicating ➢ Information radiators ➢ Communication management (L-1)
with stakeholders ➢ Burn down/burn up
charts
➢ Agile modeling
Using critical soft ➢ Negotiation ➢ Active listening (L-1)
skills ➢ Conflict resolution ➢ Facilitation methods (L-2)
➢ Distributed teams (L-2)
➢ Participatory decision models (L-2)
➢ Globalization, culture, and team
diversity (L-3)
Leading effectively ➢ Servant leadership ➢ Leadership tools/techniques (L-1)
263
Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding

264
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding

ALLIGNING STAKEHOLDERS’ UNDERSTANDING

• Agile methods recognize the importance and challenge of overcoming the
‘communication gap’ between what the customer asks for and how the
development team interprets what is asked for.
• To bridge this gap various tools and techniques are used:

– Wireframes
– Personas
– User stories
– Story Maps

265
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
WIREFRAMES
• Wireframe models are used to create a quick mock-up of the product. It can
depict individual screens and the flow between the screens.
• The diagram helps to confirm that everyone has the same understanding of the
product.
• Customer can give feedback and discrepancies can be identified and adjusted

<Example on next page>

266
 T&T
Examples of Wireframe models

267
Examples of Wireframe models
T&T

268
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
PERSONAS
• Personas are imaginary personalities that are developed and would be using
the software.
• Personas may be based on profiles of real people or composites of multiple
users
• Personas generally include the following:
– Provide description of users
– Be grounded in reality
– Be goal-oriented, specific, and relevant
– Be noticeable and actionable
– Generate focus
• Personas can help keep the team focused on delivering the features that will
be valuable.

<Example on next page> 269

 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
PERSONA EXAMPLE
Name: Joe the Movie enthusiast
Values:
Joe would like to be able to rent
movies on line from home.

Description: He should be able to search movies

Joe loves to watch movies. On an by actor, director, types, title and his
average he rents 5-6 movies per preferences.
week from rental store.
He has three children. Two of them He should be able to get movies and
watch movies as well. shows for his children.
At times they watch the same movie
many times, and end up paying late He would also like a ‘recommended’
fee. section to help him choose movies
270
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
USER STORIES
• User Stories are small sized, understandable chunks of business
functionality.
• User stories are written in the following manner:

As a <role>, I want <functionality>, so that <business benefit>

As a movie on line customer, I want to search movies by actor, so
that I can easily find movies I would like to rent.

The advantages describing the user story in this way is to force the team to
identify the user, functionality required, and the business benefit.

271
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
USER STORIES

• Mostly Acceptance Criteria is in Bulleted Points form.

272
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
CHARACTERISTICS OF EFFECTIVE USER STORY
• User stories should be simple which has following characteristics
Reduced dependencies, easy
Independent planning

Negotiable Details are added via

collaboration

Provides value to customer

Valuable
INVEST
Should not be big / vague
Estimable

Can be done in less than a week

Small by team

Testable Has acceptance criteria

273
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
HIERARCHY REQUIREMENTS

• In the hierarchy of requirement users stories are in the middle:

Feature
User Story
User story
Task 1
Task 2
Task 3

274
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T
• Epic is a large story that can be further divided into
multiple stories
• Theme is a collection of related stories

For example, “A user can search for job” can be split into
multiple stories:
– Search by Location, Salary Range, etc.
– View Job Detail
– View Company Profile

275
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
T&T

STORY MAPS
• Story maps are used to show the customer how the project will
progress over time and when certain features will be delivered.
• Story maps are a good tool to show what will come in the first
release, second release, and so on.
• Story map are usually posted on ‘information radiators’ so that they
can be seen by all stakeholders.

<Example on next page>

276
 Aligning Stakeholders’ Understanding T&T
STORY MAPS

1st release

2nd release

3rd release

277
Aligning Stakeholders’ Understanding T&T
STORY MAPS

Back Bone

Roadmap

1st
release

2nd
release

3rd
release

278
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
K&S
Level-1
INCORPORATE STAKEHOLDERS VALUE
• Incorporating stakeholders value is about bringing project
priorities in line with stakeholders priorities.
• This means that we don't initiate work that stakeholders do not
support.
• This can be done in following ways:
– Engage business representatives in prioritization of the backlog so that the
project delivers the highest priority items early to the business.
– Another way is to invite stakeholders to the retrospectives and planning
meetings so that they can give their views on higher priority items.

279
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
K&S
STAKEHOLDER MANAGEMENT Level-1

• Stakeholder Management is about comprehensively looking after the

stakeholders.
• As agile projects are different in nature as compared to traditional
projects, it may be required to make the stakeholder understand the
agile methodology
• Some concerns by stakeholders for Agile may be:
– Executives and project sponsors may be concerned about the risks of failure
due to new methodology.
– Managers may fear loss of control.
– The project team may resist new methods
– The user community would be worried if all the features will be included
– Supporting groups may be concerned about of control

280
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
K&S
Level-3

VENDOR MANAGEMENT
• Vendor Management is also a very important factor in Agile
methods.
• Vendors may require to be educated about Agile methods so that
they will respond to the changing requirements.
• Contracting methods to be used for vendor in Agile are also
different to traditional methods due to changes in scope, hence
will require understanding by the vendor.

281
 Domain III - Stakeholders Engagement >
Aligning Stakeholders’ Understanding
FREQUENTLY DISCUSS WHAT “DONE” LOOKS LIKE
• Creating a shared definition of “done” is crucial for managing
stakeholders’ expectations
• While developing the definition of “done” following elements should be
discussed and included if applicable:

• Tested: Are all units, integration, and customer tests finished?

• Coded: Has all code been written?
• Designed: Has the code been refactored to the team’s satisfaction?
• Integrated: Does the user story work from end to end?
• Builds: Does the build include new modules?
• Reviewed: Have the customer reviewed the user story?
• Accepted: Does the customer agree that the user story is finished?
282
Domain III - Stakeholders Engagement >
Communicating with Stakeholders

283
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
K&S
Level-1

COMMUNICATION MANAGEMENT

• The preferred way to communicate on agile projects is through

face-to-face communication (F2F)
• F2F communications can transfer information and also answer all
questions immediately.
• F2F has the highest bandwidth and can resolve issues quickly.

<Example on next page>

284
COMMUNICATION MANAGEMENT

K&S
Level-1

285
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
T&T

INFORMATION RADIATORS
• Information radiator is an umbrella term for a number of highly visible
ways to display information.
• These include charts, graphs, project data, boards ….
• These “visual controls” inform the stakeholders about the project status.
• “Information radiator” is opposite of “information refrigerator” where
the information is kept locked up.
• Information radiators use highly visible charts or graphs to convey, or
radiate information about the project quickly to anyone who is
interested.

<Example on next page>

286
INFORMATION RADIATOR
T&T

287
INFORMATION RADIATOR T&T

288
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
T&T

BURN DOWN AND BURN UP CHARTS

• Agile uses certain charts to show progress to the stakeholders.

• Burn down and burn up charts are used to show the progress.
• Burn down charts show the estimated effort remaining on the project
• Burn up charts show the work completed or accepted.

<Example on next page>

289
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
T&T

BURN DOWN CHARTS

• Burndown charts are used to predict your team's likelihood of completing their
work in the time available. They're also great for keeping the team aware of any
scope creep that occurs.
• Burndown charts are useful because they provide insight into how the team
works.
• For example:
• If you notice that the team consistently finishes work early, this might be a sign
that they aren't committing to enough work during sprint planning.
• If they consistently miss their forecast, this might be a sign that they've
committed to too much work.
• If the burndown chart shows a sharp drop during the sprint, this might be a sign
that work has not been estimated accurately, or broken down properly.
<Example on next page>
•
290
• Sprint Burn Down Chart is
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
T&T

BURN DOWN CHARTS

• Burndown charts are used to predict your team's likelihood of completing their
work in the time available. They're also great for keeping the team aware of any
scope creep that occurs.
• Burndown charts are useful because they provide insight into how the team
works, For example:
– If you notice that the team consistently finishes work early, this might be a sign that they aren't
committing to enough work during sprint planning.
– If they consistently miss their forecast, this might be a sign that they've committed to too much
work.
– If the burndown chart shows a sharp drop during the sprint, this might be a sign that work has not
been estimated accurately, or broken down properly.

291
 BURN DOWN CHART T&T

Sprint Burn Down Chart is

• primary method of tracking progress
• visual representation of how much work is left as of date

292
BURN UP CHART

293
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
T&T
VELOCITY

• Velocity is the measure of a team’s capacity of work per iteration

• This metric helps in gauging how much the team can do, based on the
number of user stories completed in the past iterations.
• Also helps in determining what has been accomplished, what will be
accomplished, and when can we expect the project (release) to be
completed
• Example: If the project velocity is 50 story points per iteration, and the
backlog is 500 story points, then it will take (500/50=10) iterations to
complete the work.

<Example on next page> 294

VELOCITY T&T

295
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
T&T
Average VELOCITY

Team ran 4 sprints, had velocities of 8, 11, 9 & 10

Average Velocity for 4 Sprints:

(8+11+9+10)/4 = 38/4 = 9.5

Best Velocity = 11
Worst Velocity = 8

296
 Domain III - Stakeholders Engagement >
Communicating with Stakeholders
T&T
AGILE MODELLING
• Agile modelling refers to various modelling techniques that are used on
Agile projects.
• Agile models are used to capture designs for predictive purposes to help
clarify designs, identify risks, and elements that require testing.

297
Domain III - Stakeholders Engagement >
Using Critical Soft Skills

298
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
USING CRITICAL SOFT SKILLS
Soft skills are critical for the success of the project. Good soft skills can help
in keeping the stakeholders engaged.
Following are the critical soft skills that are important for Agile Practitioners
exam point of view
1. Negotiations
2. Active listening
3. Facilitation methods
4. Globalization, culture and team diversity
5. Conflict resolution
6. Distributed teams
7. Participatory decision models
299
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
T&T
NEGOTIATIONS
• Negotiation is a very critical part of agile projects as negotiations are
used through out the agile project.
• Negotiations are not for win or loose, it is for finding a way ahead
• Negotiation can be with customers and within the team
• Negotiations are most effective when interactions between participants
are positive.
• Viewpoint of all should be kept in view while negotiating.

300
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
K&S
ACTIVE LISTENING Level-1

• Active listening is what someone is really trying to convey, rather than

just the meaning of the words they are speaking.
• Skill of active listening can be improved with practice.
• There are three levels of active listening

• Level 1: Internal listening

• Level 2: Focused listening
• Level 3: Global listening

<Example on next page>

301
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
ACTIVE LISTENING K&S
Level-1

Level 1: We interpret the words being spoken

through our own lens. While listening we ask
ourselves “how is this going to effect me”, and
miss the speaker's real message.
Level 2: We put ourselves in the mind of the
speaker. We empathize with their thoughts,
experiences, and emotions. We look for Level 3:
emotional indicators like voice, tone, Global
Level 2: listening
expression to get more information.
Level 1: Focused
Level 3: We build on the approach of Level 2, Internal listening
adding a higher lever of awareness. These listening
indictors include speaker’s movements,
posture, expressions, energy level, body
language.
302
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
K&S
FACILITATION METHODS Level-2

• Conducting effective meetings are necessary for Agile methods

• Following points should be taken into account to conduct meetings

Goals: Establish clear goals from the start so that all participants understand the
objective and are focused on it.
Rules: Establish some basic ground rules. E.g. use of cell phones, crosstalk,
respecting views of participants, starting and ending on time.
Timing: Duration of the meeting should be determined beforehand so that all
know how much time will be spent in the meeting.
Assisting: The session facilitator should make the meeting productive and
ensure that everyone gets a chance to contribute. This may include ground
rules to make sure that junior members have the opportunity to express their
thoughts.

303
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
K&S
Level-3
GLOBALIZATION, CULTURE AND TEAM DIVERSITY
• Communicating in a diversified global team is a challenge for agile
methodology.
• Extra efforts are required to understand the cultural difference between
various teams.
• Communication challenges due to differences in languages need to be
addresses and understood.
• Holding frequent meetings, face-to-face or through video/audio links can
help in bridging this gap.
• Cultural diversity can also affect the team even if they are co-located.

304
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
T&T

CONFLICT RESOLUTION

• Conflict is inevitable when ever people come together to work

• Healthy conflict due to difference in opinion is welcome, however we
have to make sure that it does not escalate to higher levels.
• Efforts to resolve conflicts should be part of facilitation techniques.
• The chart on next page shows different levels of conflicts and their
characteristics.

<Example on next page>

305
 LEVELS OF CONFLICT
Level of Name Characteristic Language Atmosphere/
conflict Environment

Level 1 Problem to solve Information sharing Open and fact based Different opinions

Level 2 Disagreement Personal protection Guarded Self protection

starts becomes
important
Level 3 Contest Wining becomes Personal attacks on Aim is to win
important others
Level 4 Crusade Protecting own Ideology Team members
groups becomes the believe that
focus members of the
other side will
not change and
should be
removed
Level 5 War Destroy others Little or none Destroy the other
party as no
constructive
outcome can be
reached
306
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
K&S
DISTRIBUTED TEAMS Level-2

• Team that is distributed over a different locations can be a challenge in

stakeholder management.
• Tools such as face-to-face communication, information radiators, rely on
co-location of the team.
• Recent surveys indicate that at least 50% of agile teams have at least one
member in different physical location.
• To over come this challenge tools such as Skye, WebEx, GoToMeeting
can be used.
• However difference in time zone still remains a challenge for many
teams.

307
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
K&S
PARTICIPATORY DECISION MODELS Level-2

• Participatory decision making is encouraged in Agile methods.

• It is a way to keep the team engaged by various methods:
Show of hands Thumbs up or down

no

yes
Fist of five voting
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
K&S
PARTICIPATORY DECISION MODELS Level-2

• Participatory decision making is encouraged in Agile methods.

• It is a way to keep the team engaged by various methods:
Show of hands Thumbs up or down

no

yes
Fist of five voting
 Domain III - Stakeholders Engagement >
Using Critical Soft Skills
K&S
PARTICIPATORY DECISION MODELS Level-2

0. (Closed Fist) I am against it

1. Serious Reservations but Vote to Move Forward
2. Some concerns but I will go along and try it
3. I will support it
4. I like this idea, sounds good
5. Absolutely, best idea ever! I’ll champion it

Note: 0 and 1 require

Domain III - Stakeholders Engagement >
Leading Effectively

311
 Domain III - Stakeholders Engagement >
Leading Effectively

LEADING EFFECTIVELY
• Leading effectively needs understanding the people. Why they are
working and what are their individual goals.
• When we align project objectives with personal objectives we get higher
level of productivity.
• Leadership is tapping into people’s intrinsic motivations.
• As leaders we need to discover why our people want to do things,
understand what motivates them and align their tasks and goals
accordingly.
• We also need to understand the difference between Management and
Leadership

312
 Domain III - Stakeholders Engagement >
Leading Effectively
MANAGEMENT VERSUS LEADERSHIP

Management Focus is on: Leadership Focus is on:

Tasks/things People

Control Empowerment

Efficiency Effectiveness

Doing things right Doing the right things

Speed Direction

Practices Principles

Command Communication

313
 Domain III - Stakeholders Engagement >
Leading Effectively
T&T
SERVANT LEADERSHIP
• Agile promotes a servant leadership model that recognizes that it is the
team members who get the work done.
• The servant leader approach redefines the role of a team leader.
• Role of a servant leader is to:
1. Shield the team from interruptions: Isolate and protect the team from
diversions, interruptions, request of work that are not part of the
project.
2. Remove impediments to progress: Clear obstacles from team path that
could cause delays or non-value work.
3. Re-communicate project values: Ensure that the project objectives are
well understood.
4. Carry food and water: Provide essential resources. Tools,
compensation, encouragement, training and professional development,
etc. 314
 Domain III - Stakeholders Engagement >
Leading Effectively
SERVANT LEADERSHIP T&T
Twelve principles of Leading Agile Projects:
1. Learn the team members’ needs.
2. Learn the project requirements.
3. Act for simultaneous welfare of the team and the project.
4. Create an environment of functional accountability.
5. Have a vision of a completed project.
6. Use the project vision to drive your own behavior.
7. Serve as a central figure in successful project team development.
8. Recognize team conflict as a positive step.
9. Manage with an eye towards ethics.
10. Remember that ethics is not an afterthought, but an integral part of our
thinking
11. Take time to reflect on the project
12. Develop the trick of thinking backwards.
 Domain III - Stakeholders Engagement >
Leading Effectively
K&S
Level-1
LEADERSHIP TOOLS/TECHNIQUES
• Leadership tools and techniques on agile projects involve taking a soft-skill
approach, rather than a directing, command-and-control project structure.
• Instead of telling people what to do, we need to create an environment where
people want to do what needs to be done.

Desired behavior of a leader:

• Honesty – Leader need to act in a transparent manner and be honest in dealing
with others.
• Forward-looking – Leaders should be able to communicate the future outcome
of the project.
• Competent – Leader should show competency in handling the project, hence
should have adequate knowledge about the project.
• Inspiring – Leader should inspire the team with the vision of the project to
generate enthusiasm in the team.
316
Questions/Answers
Test
 Domain IV
Team Performance

319
Domain IV Domain V Domain VI Domain VII

Team Problem Detection, Continuous

Adaptive Planning
Performance Resolution Improvement

Team Formation Levels of Planning

3 Tasks 5 Tasks 6 Tasks
2 Tasks

Team Adaptation
Empowerment 2 Tasks
3 Tasks

Team
Agile Sizing &
Collaboration &
Estimation
Commitment
5 Tasks
4 Tasks

10 tasks
9 tasks
320
 Domain IV - Team Performance
BOOSTING TEAM PERFORMANCE

• The success of Agile Projects depends on the output from the

team
• Hence to be successful in Agile projects we need to understand
how the team works best.
• This chapter deals with the subject of how to increase teams
performance by creating self-organizing and empowered teams,

321
 Domain IV - Team Performance
TEAM FORMATION - 2 TASKS
Task 1:
– Cooperate with the other team members to devise ground rules and internal
processes in order to foster team coherence and strengthen team members’
commitment to shared outcomes.
Task 2:
– Help create a team that has the interpersonal and technical skills needed to
achieve all known project objectives in order to create business value with
minimal delay.

322
 Domain IV - Team Performance
TEAM EMPOWERMENT - 3 TASKS
Task 3:
– Encourage team members to become generalizing specialists in order to
reduce team size and bottlenecks, and to create a high performing cross-
functional team.
Task 4:
– Contribute to self-organizing the work by empowering others and
encouraging emerging leadership in order to produce effective solutions and
manage complexity.
Task 5:
– Continuously discover team and personal motivators and de-motivators in
order to ensure that team morale is high and team members are motivated
and productive throughout the project.

323
 Domain IV - Team Performance
TEAM COLLABORATION AND COMMITMENT– 4 TASKS
Task 6:
– Facilitate close communication within the team and with appropriate external
stakeholders through co-location or the use of collaboration tools in order to
reduce miscommunication and rework.
Task 7:
– Reduce distractions in order to establish a predictable outcome and optimize the
value delivered.
Task 8:
– Participate in aligning project and team goals by sharing project vision in order to
ensure the team understands how their objectives fit into the overall goals of the
project.
Task 9:
– Encourage the team to measure its velocity by tracking and measuring actual
performance in previous iterations or releases in order for members to gain a
better understanding of their capacity and create more accurate forecasts.

324
 Domain IV - Team Performance
This chapter has the following two sections:

Practice Tool/Technique Knowledge/Skill

Understanding Team ➢ Adaptive Leadership ➢ Build empowered teams
Performance ➢ Emotional Intelligence (L-1)
➢ Build high performance
teams (L-2)
➢ Team motivation (L-1)
Team Practices ➢ Daily stand-up meetings ➢ Coaching and
➢ Co-located teams mentoring (L-1)
➢ Team space ➢ Brainstorming
➢ Agile tooling techniques (L-1)
➢ Distributed teams (L-2)

325
Domain IV - Team Performance >
Understanding Team Performance

326
Domain IV - Team Performance > Understanding
Team Performance
T&T
ADAPTIVE LEADERSHIP
• Adaptive leadership refers to the concept how we adapt while forming
and leading a team.
• Team formation follows 4 stages
1. Forming
2. Storming
3. Norming
4. Performing
5. Adjourning

327
Domain IV - Team Performance > Understanding Team
Performance
T&T
Team formation

328
Domain IV - Team Performance > Understanding Team
Performance
T&T
Team formation

Directing Coaching
Supporting
329
Delegating
 Domain IV - Team Performance >
Understanding Team Performance
T&T
EMOTIONAL INTELLIGENCE

• Emotional Intelligence is our ability to identify, asses, and influence

emotions of ourselves other individuals and groups.
• It is a leadership trait that helps in building of teams and keeping
people motivated
• Emotional Intelligence can be improved by a step by step approach.
• It starts with self awareness, self management, social awareness and
social skills.
• The diagram on the next page 4 quadrants of Emotional Intelligence
and the way of improving one’s EI.

330
Domain IV - Team Performance > Understanding Team
Performance
EMOTIONAL INTELLIGENCE
T&T
Self Others

Self Management Social skills

Self-control Regulate
Self-control Inspirational leadership
Adaptability Developing others
Drive and motivation Teamwork & collaboration

Self Awareness Social Awareness

Recognize
Empathy
Self Confidence Organizational awareness
Emotional Self-awareness Understanding the
Accurate self assessment environment
331
Domain IV - Team Performance > Understanding
Team Performance
K&S
Level-1
BUILD EMPOWERED TEAMS
Empowered teams are self-organizing and self-directing.
Self-Organizing Team
• Empowered teams are free from command-and-control
management and can use their own knowledge to determine how
best to do their job.
• They manage their own work using the expertise available with them
• The ‘servant leader’ allows the team to do what is necessary to
achieve the goals by ‘downward serving’ the team.

332
Domain IV - Team Performance > Understanding
Team Performance
K&S
Level-1
BUILD EMPOWERED TEAMS
Empowered teams are self-organizing and self-directing.
Self-Directing Team
• Self-Directing teams are teams that work collectively to create team
norms and make their own local decisions.
• They figure out what is best for them to accomplish the work they
are to do.
• The Project manager supports the team in forming and storming
phases.

333
Domain IV - Team Performance > Understanding
Team Performance
K&S
Level-2
BUILD HIGH PERFORMANCE TEAMS
High performance teams are defined as a small number of people with
complimentary skills who are committed to a common purpose,
performance goals and approach for which they hold themselves
mutually accountable.
1. Create a shared vision for the team
2. Set realistic goals
3. Limit the team size to 12 or less
4. Build a sense of team identity
5. Provide strong leadership

334
Domain IV - Team Performance > Understanding
Team Performance
K&S
BUILD HIGH PERFORMANCE TEAMS Level-2

Characteristics of such teams are:

1. They are self organizing rather than role or title based

2. They are empowered to make decisions
3. They truly believe that as teams they can solve any problem
4. They are committed to team success
5. The team owns its decisions and commitments
6. Trusts vs. fear or anger, motivates them
7. They are consensus-driven, with full divergence and then
convergence.
8. They live in a world of constant constructive disagreement

335
Domain IV - Team Performance > Understanding
Team Performance
K&S
Level-1
TEAM MOTIVATION
• Team motivation is the art of encouraging people towards commitment and
dedication to bring passion and innovation to the organization
• To achieve team motivation one needs to find out motivator for individual
members and then align them in one direction.
• Good communication can help in discovering motivation factors .

Levels of Motivations +

Passive Active Committed Passionate

- Compliance Participation Dedication Innovation
Undermining/
Resistance
336
Domain IV - Team Performance >
Team Practices

337
 Domain IV - Team Performance >
Team Practices
T&T
DAILY STANDUPS
Daily stand-up are the core part of the Agile teams. They are short,
focused and time-boxed to 15 minutes (max).
Attendees are asked to answer 3 questions only:

1. What have you worked on since the last meeting?

2. What do you plan to finish today?
3. Are there any road blocks or impediments to your work?

338
 Domain IV - Team Performance >
Team Practices
DAILY STANDUPS T&T

339
 Domain IV - Team Performance >
Team Practices
T&T
DAILY STANDUPS

340
 Domain IV - Team Performance >
Team Practices
K&S
Level-1
COACHING AND MENTORING

• Coaching and Mentoring helps in keeping the team on track,

overcome issues, and continually improve their skills.
• Done at two levels: Whole team and individual level.
• Whole Team coaching: At the beginning of iteration during Iteration
Planning and at the end of Iteration during Retrospective
• Individual Coaching: At the Iteration mid-point to help individuals in
resolving issues.

341
 Domain IV - Team Performance >
Team Practices
K&S
Level-1
COACHING AND MENTORING

Key points in Coaching and Mentoring

• Meet them half way: Do no push people directly to end point,
instead coach them so that they reach the end point themselves.
• Guarantee Safety: Declare to the team that all coaching conversation
will be kept confidential.
• Partner with managers: Involve functional managers in the agile
process so that they understand the performance criteria of the team
members.
• Create positive regard: Develop compassion and desire to help
others.

342
 Domain IV - Team Performance >
Team Practices
K&S
Level-1
BRAINSTORING TECHNIQUES
Brainstorming is used to identify options, solve issues, and find ways to
improve processes. Such as:
• Product roles that will be featured in personas
• The items that should go in the minimal marketable features list for
release
• Potential risk that could impact the project
• Solutions to a problem raised at retrospective

343
 Domain IV - Team Performance >
Team Practices
K&S
Level-1
BRAINSTORMING TECHNIQUES
Following techniques can be used:
1. Quite Writing
– Team members are given time to write ideas individually. This limits
peer influence. The ideas are discussed facilitated by the facilitator.
2. Round-Robin
– In this format the facilitator goes around the table to give everyone a
chance to express their ideas. This format has the advantage of
allowing ideas to be built on each other.
3. Free-for-All
– This format allows all to give their ideas spontaneously which are
discussed. The disadvantage is that quieter individuals may not get a
chance to speak.

344
 Domain IV - Team Performance >
Team Practices
T&T
TEAM SPACE

• Team Space is the designated environment where the team

members conduct their everyday work.
• Since the preferred means of communications is face-to-face, it is
recommended that the team be placed in a common work area for
better collaboration and information sharing.
• Usually an open space such as a conference room can be used as a
space for agile team.
• There should be plenty of wall space for placing white boards, and
other information radiators in the space.

345
 Domain IV - Team Performance >
Team Practices
T&T K&S
Level-1
CO-LOCATED TEAMS

• Agile methods promote using co-located teams and creating

collaborative team space.
• The team is located in one room, called the war room.
• There are no individual cabins.
• This layout promotes better communication, understanding, and
transparency.
• Some important aspects of co-location of teams are:
1. Caves and common
2. Osmotic Communication
3. Tacit Knowledge

346
 Domain IV - Team Performance >
Team Practices
T&T K&S
CO-LOCATED TEAMS Level-1

1. Caves and common

• Some companies provides private offices where team members can
go to make private calls. These offices can also be used by members
who want to work in isolation for work requiring high level of
concentration for short periods of time.
2. Osmotic Communication
• Osmotic communication refers to the useful information that flows
from team members as part of everyday conversations.
• This ability to pick up on things is a major benefit of co-location.
3. Tacit Knowledge
• Tacit knowledge is knowledge that is not written down but is instead
supported through collective group knowledge. To better facilitate
tacit knowledge it is better to limit the size of the team to 12 or less.
347
 Domain IV - Team Performance >
Team Practices
K&S
Level-2
DISTRIBUTED TEAM
• Distributed teams are those teams in which at least one member is
working off-site.
• About 50% of Agile teams are distributed.
• Main challenge for distributed team is to replicate benefits of face-
to-face communication.
• Some of the tools that can be used for such purpose are:
– Video-conferencing – useful for stand-up and other meetings
– Web-based meeting tools – ‘go-to-meeting, WebEx, Conferencing.pk
– Instant messaging – WhatsApp, SMS, Viber,
– Presence based applications – Cisco® Unified Communications Solutions
unify voice, video, data, and mobile applications on fixed and mobile
networks
– Interactive white-boards – connects to computer or projector
348
 Domain IV - Team Performance >
Team Practices
T&T
AGILE TOOLING

Low-Tech, High-Touch tools

• Agile teams prefer to use Low-Tech, High-Touch tools for
communication and collaboration.
• Tools such as task boards, 3inx5in cards for user stories, post-it
notes, white boards, are used extensively by agile teams.
• Besides there are also electronic tools that are available for agile
teams, such as, Agile Project Management Software, Virtual card
walls, smart boards, automated testing tools, automated build tools,
etc.

349
Questions/Answers
Test
 Domain V
Adaptive Planning

352
Domain IV Domain V Domain VI Domain VII

Team Problem Detection, Continuous

Adaptive Planning
Performance Resolution Improvement

Team Formation Levels of Planning

3 Tasks 5 Tasks 6 Tasks
2 Tasks

Team Adaptation
Empowerment 2 Tasks
3 Tasks

Team
Agile Sizing &
Collaboration &
Estimation
Commitment
5 Tasks
4 Tasks

10 tasks
9 tasks
353
 Domain V - Adaptive Planning
ADAPTIVE PLANNING

Adaptive planning is an approach where planning is carried out

throughout the project.

354
 Domain V - Adaptive Planning
LEVELS OF PLANNING – 3 TASKS
Task 1:
– Plan at multiple levels (strategic, release, iteration, daily) creating
appropriate detail by using rolling wave planning and progressive
elaboration to balance predictability of outcomes with ability to exploit
opportunities.
Task 2:
– Make planning activities visible and transparent by encouraging participation
of key stakeholders and publishing planning results in order to increase
commitment level and reduce uncertainty.
Task 3:
– As the project unfolds, set and manage stakeholder expectations by making
increasingly specific levels of commitments in order to ensure common
understanding of the expected deliverables.

355
 Domain V - Adaptive Planning
ADAPTATION – 2 TASKS
Task 4:
– Adapt the cadence and the planning process based on results of periodic
retrospectives about characteristics and/or the size/complexity/criticality of
the project deliverables in order to maximize the value.
Task 5:
– Inspect and adapt the project plan to reflect changes in requirements,
schedule, budget, and shifting priorities based on team learning, delivery
experience, stakeholder feedback, and defects in order to maximize business
value delivered.

356
 Domain V - Adaptive Planning
AGILE SIZING AND ESTIMATION – 5 TASKS
Task 6:
– Size items by using progressive elaboration techniques in order to determine
likely project size independent of team velocity and external variables.
Task 7:
– Adjust capacity by incorporating maintenance and operations demands and other
factors in order to create or update the range estimate.
Task 8:
– Create initial scope, schedule, and cost range estimates that reflect current high
level understanding of the effort necessary to deliver the project in order to
develop a starting point for managing the project.
Task 9:
– Refine scope, schedule, and cost range estimates that reflect the latest
understanding of the effort necessary to deliver the project in order to manage
the project.
Task 10:
– Continuously use data from changes in resource capacity, project size, and
velocity metrics in order to evaluate the estimate to complete.

357
 Domain V – Adaptive Planning
Adaptive planning is based on the premise that all early plans are likely
to be flawed, therefore re-planning and adaptation activities should be
scheduled in the project.
This chapter has 3 sections
Practice Tool/Technique Knowledge/Skill
Planning concepts ➢ Time boxing ➢ Value based analyses (L-2)
➢ Progressive Elaboration ➢ Value based decomposition
➢ Process tailoring (L-1)
➢ Minimally marketable ➢ Agile games (L-3)
feature
Estimation ➢ Wideband Delphi ➢ Time, budget, and cost
➢ Planning poker estimation (L-1)
➢ Ideal time ➢ Agile project accounting
➢ Affinity estimating principles (L-3)
Agile Plans ➢ Iteration and release ➢ Agile Charters (L-2)
planning ➢ Business case development
358 (L-2)
 Domain V – Adaptive Planning
Exam will test knowledge and ability on:

1. Plan at multiple levels.

2. Engage the team and customer in planning.
3. Manage expectations by frequently demonstrating progress and
extrapolating velocity.
4. Tailor processes to the project’s characteristics.
5. Update plan based on project priorities.
6. Ensure encompassing estimates that account for risks, distractions,
and team availability.
7. Use appropriate estimate ranges to reflect the level of uncertainty
in the estimates.
8. Base projections on completion rates.
9. Factor in diversion and outside work.
359
 Product Vision Statement
• Vision statement is created to provide clear direction at the beginning of
Agile project on the strategic objectives behind creating the product. It
outlines what specific product needs to be developed, who should this
product be built for, and what differentiates this product from current
products on the market.
• Vision Statement is the first artifact created in agile and it sets the stage
for all future scope and development; It expresses the goals for the
product.
• Product vision statement should always be in plain sights so that any one
who has a stake in project, is interested in project or is working directly on
project can review it - in order to ensure that product vision is constantly
being supported.

360
Product Vision Statement - Format
• It allows the project team members the ability to explain the
project to someone within two minutes - sort of the elevator
pitch.

• For (Target Customer)

Who (Statement of Need/ Opportunity)
The (Product) is a (Product category)
That (Compelling Benefit)
Unlike (Primary competitive alternative)
Our Product (Primary differentiation)

361
 Strategy Meeting
• The Strategy meeting is held to kick off the project, and it driven by a vision
associated with a specific strategic business need or goal.

• Strategy Meeting - Steps: Each of these step has an output and artifact.

• Create Product Vision Statement

• Create Initial Epic User Stories:

– This is the first gathering of our project, it's important to create these statements as a starting
point for requirements or features definitions and for initial estimating purposes. These epic
user stories will later on be decomposed through out the project until they become detailed
enough to assign the specific task that are necessary to complete them and implement them
as part of our product.

• Create Initial Detailed User Stories:

– Further decomposition should not be pursued at this time because you may be derailing the
overall course of strategy meeting.

362
 Strategy Meeting
• Determine Initial User Story Prioritization:
– Which user story pose highest risk to the organization, and where to organization has
most control over which of these user stories and features, and which one of these will
be easiest to implement and demonstrate.

• Create Initial Product Roadmap:

– Once all initial user stories has been created and prioritized; they will be placed in
product roadmap - A visual timeline of major product features that support the vision
statement.
– This will enable the strategy meeting attendees to see the big picture of when
these major product features will be developed, and released over the life of
the entire project.

• Create Initial Product Backlog

363
 Release Planning Meeting
• Steps:
• PO reviews product attributes with meeting attendees, so they get a high level
understanding of the project as a whole and why it will need to be broken into
different releases.
– At minimum this should always include the Review of Product Vision Statement.

• Key dates and milestones are determined and reviewed to ensure all major
constraints are identified, and discussed in detail, in order to determine their
effect on your project.

• PO will present initial product backlog that was created during the strategy
meeting, and this product backlog may contain both epic and detailed user stories.

• PO will present each user story and development team will ask questions to
understand user stories.
• Development team will know more about the specifics of what is involved in
developing each user story that are presented.
• Perform user story estimation using relative sizing.

364
 Release Planning Meeting
• Determine the length of sprints (1-4 weeks) for the project.
• Determine Release Theme, which describes the overall goal of the release and
what features are expected to be delivered at the end of the release. Release 12 or
Packaging Release

• PO creates the release product backlog by putting all user stories from initial
product backlog that have been identified for first release in the release backlog
which is a subset of overall backlog.

• PO asks each stakeholder attending the meeting and get their consensus on the
specific user stories that will be developed and delivered as part of the release.
– It's difficult to achieve consensus depending on the number of stakeholder present in the
meeting and their individual needs.
– if an impas is reached, either a majority vote can be taken or the PO have to make the final
decision since the PO is the representative of the customer voice.

• Finally, PO states their commitment to proceed with this particular release.

365
 Release Planning Meeting
Note:
• At this time in project, the development team may not be finalized
however PO and SM may want certain initial development team members
to be present to help with prioritization and estimation of the features
that are in the initial and future releases.

• Some organizational departments are looking for high level scope and
high level estimates at the beginning of the project. This occurs during the
release planning meeting, and this is why it is important to have key
management stakeholders or at least their representatives present at this
meeting.

366
Domain V – Adaptive Planning >
Planning Concepts

367
 Domain V – Adaptive Planning >
Planning Concepts
T&T

TIME-BOXING

• Time-boxes are short, fixed duration periods of time in which

activities of work are undertaken.
• If the work planned for the time-box is not complete when the time
runs out, then the work is stopped and move the uncompleted work
into another time-box.
• E.g. Daily stand-up meeting are time-boxed to 15 minutes.
• Iteration is time-boxed to 2 weeks

368
 Domain V – Adaptive Planning >
Planning Concepts
TIME-BOXING T&T

must must must

should could

Iteration
Time-box
Features for iteration
 Domain V – Adaptive Planning >
Planning Concepts
TIME-BOXING T&T

Will go in later iteration

could

Iteration
Time-box

Feature left out

Size of time-box
is not increased
 Domain V – Adaptive Planning >
Planning Concepts
T&T
PROGRESSIVE ELABORATION
• Progressive Elaboration is adding more details to plans as the more
information is available.
• In Agile there is also lessons learnt through retrospectives which are
used in later plans.
• Idea is to create accurate:
– Plans
– Estimates
– Risk assessments
– Architectural designs
– Acceptance Criteria
– Test scenarios

371
 Domain V – Adaptive Planning >
Planning Concepts
T&T
PROCESS TAILORING
• Process Tailoring is the process of identifying areas where the improvement
can be made.
• Retrospective reviews are the main triggers for driving process changes
carried out at the end of each iteration with team and business
stakeholders.
Following questions are asked in retrospectives:
1. What is going well?
2. What areas could use improvement?
3. What should we be doing differently?

• Solutions for problems are identified in brainstorming sessions and

implemented in subsequent iterations

372
 Domain V – Adaptive Planning >
Planning Concepts
T&T

MINIMALLY MARKETABLE FEATURE (MMF)

• Any release of features has to useful and valuable to the customer

• The term ‘minimally marketable feature (MMF)’ refers to this
package of functionality that is complete enough to be useful to
users or market.
• In software development, it can be possible to transfer increments of
the final product to the users early so that business can start getting
benefits from applications.
• These incremental releases can allow early return on investment.

373
 Domain V – Adaptive Planning >
Planning Concepts
T&T

MINIMALLY MARKETABLE FEATURE (MMF)

Development of Automated Teller Machine (ATM)

MMF Additional Releases

➢ Dispense money ➢ Accepts cash deposits
➢ Display balance ➢ Accepts Check deposits
➢ Displays mini-statement ➢ Printouts statements
➢ Keeps user information secure

374
 Domain V – Adaptive Planning >
Planning Concepts
K&S
Level-2
VALUE-BASED ANALYSES
• Value based analyses is the process of considering the business value
of work items and acting accordingly.

1000
2000 Which one to select
Business
Benefit Business
5000 Benefit
3000
Cost to build
Cost to build 1000
4000
Feature 2
Feature 1
 Domain V - Adaptive Planning >
Planning Concepts
K&S
Level-1

VALUE-BASED DECOMPOSITION AND PRIORITIZATION

• Value-based decomposition and prioritization is the process to

eliciting requirements for stakeholders, ranking those requirements,
and then pulling the prioritized requirements into the development
process.
• The chart on the next page shows ROI for different features and the
criteria of selecting them.

Chart on next page >>

 Domain V - Adaptive Planning >
Planning Concepts
K&S
Level-1
VALUE-BASED DECOMPOSITION AND PRIORITIZATION
 Domain V - Adaptive Planning >
Planning Concepts
K&S
Level-3
AGILE GAMES (COLLABORATIVE/INNOVATION GAMES)

• Innovation games, also known as collaborative games, are facilitated

workshops technique that agile teams use to help stakeholders
better understand the complex issues and reach consensus on an
agreed-upon solution.

Examples:
1. Remember the future
2. Prune the product tree
3. Speedboat or sailboat
 Domain V - Adaptive Planning >
Planning Concepts
AGILE GAMES (COLLABORATIVE/INNOVATION GAMES) K&S
Level-3
1. Remember the future:
Stakeholders are asked to imagine that the release is out and write a
report to their manager saying how the release went. The notes from
various stakeholders help in determining features for the product.
 Domain V - Adaptive Planning >
Planning Concepts
AGILE GAMES (COLLABORATIVE/INNOVATION GAMES) K&S
Level-3
2. Prune the Product tree:
A tree is drawn on a board and stakeholders are asked add features
using sticky notes considering the tree to be a release.
 Domain V - Adaptive Planning >
Planning Concepts
AGILE GAMES (COLLABORATIVE/INNOVATION GAMES) K&S
Level-3
3. Speedboat or Sailboat:
Stakeholder identify risks and opportunities and stick them on boat
drawn on the white board.
Opportunities will keep the boat floating

Risks will sink the boat

Domain V - Adaptive Planning >
Estimation

382
 Domain V - Adaptive Planning >
Estimation
ESTIMATION for knowledge workers is difficult because these projects
are complex and often new to the organization.
Following are some points to consider while developing estimates:
• Why do we estimate? Estimates are required for sizing and approving
projects.
• How are estimates created? By determining size, effort, schedule,
cost.
• When to make estimate? Estimates should not be done upfront when
we have least knowledge about the project. Instead estimate should
be done throughout the project.
• Who should estimate? Estimate should not be done by the Project
Manager who has less knowledge about the project rather it should
be done by the whole team who have more knowledge about the
project.

383
 Domain V - Adaptive Planning >
Estimation
WIDEBAND DELPHI T&T

• Participants are asked to read a problem and give their feedback

anonymously which are plotted. The problem is discussed and
feedback taken and plotted again. This is repeated till a consensus
reached.

384
 Domain V - Adaptive Planning >
Estimation
T&T
IDEAL TIME
• Ideal time is the time required to do a certain work without any
interruptions.
• It is used for estimation.
• Interruptions are taken into account based on the environmental
factors
• For example in a 40 hour week, 5 hours may not be available for work
due to lunch breaks. (i.e. 12.%).

385
 Domain V - Adaptive Planning >
Estimation
T&T
RELATIVE SIZING / STORY POINTS
• To overcome the difficulty of estimation in absolute terms relative
sizing is used.
• If we say that the market is 2 streets away, it is easily understood as
compared to that is 1.2km away.
• So Agile uses the method of using story points for estimating work.
• Task are divided into story points based on how easy or complex they
are.
• For example fixing the color of a screen may be 1 point, compared to
developing a screen which may be 4 story points.

386
 Domain V - Adaptive Planning >
Estimation
T&T
RELATIVE SIZING / STORY POINTS
To use this system the team needs to the following:

1. Team should own the story points: This means that the story point
should be created by the team’s through consensus.
2. Story point estimates should be all inclusive: All known activities
should be included in story points.
3. Sizes should be relative: Meaning a 2 point user story should take
twice the effort as required for a 1 point user story.
4. Complexity, work effort, and risk should all count: The total time
required to complete the work depends on the work’s complexity,
the effort involved, and its risk. All three attributes are assessed
when the team is estimating user stories.

387
 Domain V - Adaptive Planning >
Estimation
T&T
RELATIVE SIZING / STORY POINTS

• Does not equate to a specific unit of time

• Fibonacci Sequence
– Number sequence used in Agile Estimation techniques
– Each number is sum of previous two numbers
– 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144

• Team establishes a baseline Story

• Baseline is give a number from the Fibonacci Sequence
• All other User Stories are evaluated relative to the baseline

388
 Afiniti Estimating
• Facilitator reviews the user stories with Project Team
• Without talking, the team works together to arrange the
stories in size order
• Facilitator leads a discussion of initial estimate
• Team has additional opportunities to silently make
adjustments until the team reaches a consensus for all user
stories.

389
 Afiniti Estimating
• Useful to quickly and easily estimate a large number of user
stories
• Helpful when starting a new project with a large project
backlog

• Best conducted on Product Backlogs larger than 20 items. It is

best when you have at least 40 items which allows for
groupings to easily become apparent

390
 Domain V - Adaptive Planning >
Estimation
T&T
AFFINITY ESTIMATING
• Affinity estimating is the process of grouping requirements into
categories or collections.
• One way is to make columns based on sizes on the board and stick
user stories card in the appropriate column.
• This way new user stories can be checked to see where they would fit.

391
 Domain V - Adaptive Planning >
Estimation
T&T
AFFINITY ESTIMATING

392
 Domain V - Adaptive Planning >
Estimation
T&T
AFFINITY ESTIMATING

393
 Domain V - Adaptive Planning >
Estimation
PLANNING POKER T&T

• Can use specialized cards based on Fibonacci Sequence or a standard

deck
• Adjusted Fibonacci sequence
• 0 ½ 1 2 3 5 8 13 20 40 100 α ?
• All estimators have identical cards
• Can be done for geographically distributed teams through
collaborative s/w applications

394
 Domain V - Adaptive Planning >
Estimation
PLANNING POKER T&T

• Chaired by a Moderator
• Feature is read to the team with explanation by Product owner
• Team ask Questions, discuss Constraints, Assumptions
• Each member places his card face down
• All cards are turned over at same time

395
 Domain V - Adaptive Planning >
Estimation
PLANNING POKER T&T

• If estimates are different, outliers are discussed

• Repeat until consensus is reached or maximum rounds (3) is reached
• Use Kitchen time to limit discussions in each round

• Five Finger Voting - Rules used for consensus.

396
 Domain V - Adaptive Planning >
Estimation
PLANNING POKER T&T

Anchoring
• When a team member exerts an undue influence on the rest of the
team.
• Concepts we discussed are designed to avoid this as much as possible.

397
 Domain V - Adaptive Planning >
Estimation
PLANNING POKER - Cards T&T

398
 Domain V - Adaptive Planning >
Estimation
K&S
Level-1
TIME, BUDGET, AND COST ESTIMATION
• Steps involved in estimating:
1. Determine the size of the project in story points or ideal time
2. Calculate the effort for work in hours or person days (or person
weeks or months) based on the team’s availability and capacity of
the team.
3. Convert the effort into schedule by factoring the team size, required
resources, and dependencies
4. Calculate the cost by applying labor rates and adding in other project
cost elements

399
 Domain V - Adaptive Planning > Estimation K&S
Level-1

TIME, BUDGET, AND COST ESTIMATION - Example

• The estimated size of the project is 500 ideal time days. Three people will work on the
project. Their hourly rate and availability is:
• AA – $50 an hour. 80% of the time.
• BB – $80 per hour. 70% of the time.
• CC – $95 per hour. 75% of the time.
• Their average availability can be calculated as: (80+70+75)/3=75%
• The work will take 500/.75 = 670 person days
• However later the availability of the team improves to 83%.
• Hence the total days required is 500/.83=603 days.
• With 3 persons working on the project, the number of days required will be 603/3 = 201
days.
• Using 21 days in month the number of months can be calculated as 201/21 = 9.6 mnths
• Convert time into hours for each resource at 168 working hours per month.
• (9.6 months x 168 hours = 1613 hours)
• Cost can be calculated as = (time x resource rate) + other costs
• Cost is: (1613x50) + (1613x80) + (1613x95) = $362,925 + 10% contingency

400
 Domain V - Adaptive Planning >
Estimation
K&S
Level-3

AGILE PROJECT ACCOUNTING PRINCIPLES

• Generally cost of knowledge worker project is high due to high
manpower cost.
• Project managers need to know and understand the accounting
principles used by the organization.
• Project Managers need to understand what costs are to be included.
• Cost such as other travel, licenses, specialized services, need to be
taken into account for costing purposed.
• There are different ways to account for labor cost. One way is to
divide the annual salary by 52, to determine weekly salary. Another
way is to consider full burdened cost, which salary plus cost of office,
computers, benefits, etc. This could be 50% higher than the salary.

401
 Domain V - Adaptive Planning >
Estimation
AGILE PROJECT ACCOUNTING PRINCIPLES K&S
Level-3

Costing for a project with 2 week iteration

Role Annual Fully Cost per Time on Adjusted

Salary burdened iteration project cost per
labor cost iteration
Product owner 120,000 180,000 6,925 100% 6,925
Developer 100,000 150,000 5,770 100% 5,770
Developer 80,000 120,000 4,615 50% 2,310
Analyst 100,000 150,000 5,770 100% 5,770
Tester 90,000 135,000 5,195 100% 6,925
Full Total cost $25,970
labor of one
cost/26 iteration
402
Domain V - Adaptive Planning >
Agile Plans

403
 Domain V - Adaptive Planning >
Agile Plans

AGILE PLANS
• Agile planning is different from the traditional planning:

1. Agile planning is less of an upfront effort, instead it is done through

out the project
2. Mid-course adjustments are normal
3. Trial and demonstration give the true requirements, which are re-
planned

404
 Traditional Project Management Approach
EFFORT

TIME

405
 Agile Project Management Approach

Iteration 1 Iteration 2 Iteration 3 ….

406
 Domain V - Adaptive Planning >
Agile Plans
AGLIE CHARTERS K&S
Level-2

• Charter is the first document produced for a project. It describes the

project goals, its purpose, composition, and approach and it provides
authorization from the sponsor for the project to proceed.
• Agile Charters can be lightweight worksheets or fairly detailed
documents.
• Agile charters acknowledge that the scope may change and that
initially some aspects of a project may be unknown.
• Therefore, rather than trying to fully specify the scope, agile charters
characterize the goals envisioned for the project. They also describe
the process and approaches that the team should use and the
acceptance criteria.

407
 Domain V - Adaptive Planning >
Agile Plans
AGLIE CHARTERS K&S
Level-2
• Typically Agile Charters answer a subset of 5Ws&H questions

1. What is the project about? A high level description of the project’s

vision, mission, goals, and objectives.
2. Why is it being undertaken? Business rational for the project.
3. When will it start and end? The project start and target end dates
4. Who will be engaged? List of Project participants and stakeholders
5. Where will it be done? Details of Work site, deployment
requirements, etc.
6. How will it be undertaken? A description of the approach, agile
methods to be used.

408
 Domain V - Adaptive Planning >
Agile Plans K&S
Level-2

BUSINESS CASE DEVELOPMENT

• Agile plans also require development of business case for undertaking
projects.
• Business case describes why the sponsoring organization should
undertake the project.
• It should contain:
– Project overview: Brief description of the project
– Anticipated costs: Estimate including contingency
– Anticipated benefits: Benefits such as cost saving, additional income, etc
– Business model: Calculation of ROI, NPV, IRR
– ROI and assumptions: List of assumptions
– Risk of not taking up the project: Risks if the project is not undertaken
– SWOT/PEST analyses: To identify risks and opportunities
– Recommendations: Sponsors recommendations. Such as Mandatory,
critical, High, Medium or nice to have.
409
 Domain V - Adaptive Planning >
Agile Plans T&T
ITERATION AND RELEASE PLANNING
• An iteration is a short development period (2-4 weeks), while a
release is group of iterations that results in the completion of a
valuable deliverable on the project. Project will have one or more
releases and releases will have one or more iterations.
• The idea behind Iteration and release planning is that releases with
higher ROI should be completed before the others with lower ROI.

410
 Domain V - Adaptive Planning >
Agile Plans
T&T
ITERATION PLANNING
• In iteration planning we ask the team to select user stories that the
customer has indicated as high priority items and that can be
developed, tested and delivered within the iteration.
• Based on the velocity of the team, the teams in consultation with the
product owner decides feature/tasks to do in the iteration.
• The product owner comes with a fresh list of features to be included
in the iteration in the planning meeting. This is discussed in the first
half of the meeting. In the second half of the meeting the team
discuss the selected feature and plan the iteration.
• The number of features selected are based on the velocity of the
team.

411
ITERATION PLANNING

412
ITERATION PLANNING

413
Questions/Answers
Test
 Domain VI
Problem Detection, Resolution

416
Domain IV Domain V Domain VI Domain VII

Team Problem Detection, Continuous

Adaptive Planning
Performance Resolution Improvement

Team Formation Levels of Planning

3 Tasks 5 Tasks 6 Tasks
2 Tasks

Team Adaptation
Empowerment 2 Tasks
3 Tasks

Team
Agile Sizing &
Collaboration &
Estimation
Commitment
5 Tasks
4 Tasks

10 tasks
9 tasks
417
 Domain VI – Problem detection and
resolution
5 TASKS
Task 1:
– Create an open and safe environment by encouraging conversation and
experimentation, in order to surface problems and impediments that are slowing
the team down or preventing its ability to deliver value.
Task 2:
– Identify threats and issues by educating and engaging the team at various points
in the project in order to resolve them at the appropriate time and improve
processes that caused issues.
Task 3:
– Ensure issues are resolved by appropriate team members and/or reset
expectations in light of issues that cannot be resolved in order to maximize the
value delivered.
Task 4:
– Maintain a visible, monitored, and prioritized list of threats and issues in order to
elevate accountability, encourage action, and track ownership and resolution
status.
Task 5:
– Communicate status of threats and issues by maintaining threat list and
incorporating activities into backlog of work in order to provide transparency.

418
 Domain VI – Problem Resolution and
This chapter has two sections
detection
Practice Tool/technique Knowledge/skill
Identifying problems ➢ Cycle time ➢ Project and Quality Standard
➢ Escaped defects (L-1)
➢ Failure modes and
alternatives (L-3)
➢ Variance and trend analyses
(L-3)
➢ Control limits (L-3)

Resolving problems ➢ Continuous integrations ➢ Problem solving (L-1)

➢ Risk based spike
➢ Frequent verification and
validation
➢ Test-driven development
➢ Acceptance test-driven
development

419
Domain VI - Problem detection and
resolution > Identifying Problems

420
Domain VI - Problem detection and resolution >
Identifying Problems

The concepts that will be discussed in this section are focused

on finding issues, problems, and concerns.

Cycle time, daily standups, are mechanism for identifying

problems.

When concerns are raised at the daily standup meetings, we

need to further investigate the issue and determine if there is a
problem.

421
Domain VI - Problem detection and resolution >
Identifying Problems
T&T
CYCLE TIME
• Cycle time is the measure of how long to get things done.
• Cycle time is related to work in progress (WIP).
• Formula for calculating cycle time:
Cycle time = WIP/throughput
• Example: A factory makes 25 AC units per day. They have 100 under
production on any given time. Calculate the average time it takes to
manufacture one AC unit
WIP = 100. Throughput = 25.
Cycle time = 100/25 = 4 days.
It takes 4 days to make one AC unit
• If the cycle time increases, it would indicate some problem in the
process.
422
Domain VI - Problem detection and resolution >
Identifying Problems
T&T

ESCAPED DEFECTS
• Escaped defects are those defects that are not discovered during the
processes of testing and validating and make it to the customer.
• Escaped defect are most costly to fix.
• Projects track escaped defects back to the release they originated in or
escaped from.
• This helps the quality assurance and quality control process over time.

423
ESCAPED DEFECTS

424
Domain VI - Problem detection and resolution >
Identifying Problems
K&S
Level-1

PROJECT AND QUALITY STANDARDS

• Problem detection and resolution is closely related to quality
management.
• Quality standards and practices should be part of project management.
• Quality should be measured using tools such as defect metrics, variance
and trend analyses, root cause analyses, etc.
• Action should be taken when issues are found.

425
Domain VI - Problem detection and resolution >
Identifying Problems K&S
Level-3
FAILURE MODES AND ALTERNATIVES
Despite all the efforts that goes into planning, failure do occur. Some of the reason
why failures happen are as follow:

1. Mistakes by people: people do make mistakes. Doing work in iterations can

reduce discovery of mistakes early.
2. Preferring to fail conservatively: When people face uncertainty, they prefer to
revert back to familiar (non-agile) approach, which could lead to failures
3. Inventing rather than researching: Many people have the tendency of inventing
new ways to do things rather than finding out the best way of doing the work
through research.
4. Being creature of habit: People are creatures of habit and it is difficult to
change them. So it is difficult to get them to adopt new methods.
5. Being inconsistent: Some people are inconsistent in following processes. This
can result in project failures.

426
Domain VI - Problem detection and resolution >
Identifying Problems
K&S
Level-3
• Variance: is the measure of how far apart things are (how much the
data vary from one another)
– e.g. the distribution of data points, small variance indicates the data
tend to be close to the mean (expected value)

• Trend analysis provides insights into the future which is

more important for problem detection

• Variance and trend analysis is important for controlling (problem

detection) and continuous improvement, e.g the process to ensure
quality

427
Domain VI - Problem detection and resolution >
Identifying Problems
K&S
Level-3
VARIANCE AND TREND ANALYSES
• Variance can be expected, however we need to understand the tolerance
limit of variance.
• Another thing to consider is that threshold should also be determine so
that it can be know when to intervene and correct things.
• Some level of variance can be tolerated is some cases.

428
Domain VI - Problem detection and resolution >
Identifying Problems
K&S
Level-3
Control limits/Threshold for Agile projects
By plotting the time to delivery / velocity / escaped defects / etc. as a
control chart
• if some data fall outside the upper / lower control limits, a root cause
analysis should be performed to rectify the issue
– common cause – systematic issue, need to be dealt with through
trend analysis
– special cause – happens once only due to special reasons
• another example is the WIP limit in Kanban boards

429
Control Charts

430
Variance and Trend Analysis

431
Domain VI - Problem detection and
resolution > Resolving Problems

432
Domain VI - Problem detection and resolution >
Resolving Problems

• This section is about various techniques that are used in

agile to quickly resolve problems before they get too big.
 Domain VI - Problem detection and resolution >
Resolving Problems
T&T

CONTINUOUS INTEGRATION

• Continuous is a software development process.

• Using this technique the team frequently integrates new and
changed code into the product code repository.
• This helps in minimizing the integration problems resulting from
people making multiple changes on the same code.
Domain VI - Problem detection and resolution >
Resolving Problems
T&T
CONTINUOUS INTEGRATION

Continuous
Source Code Integration
Source Control System
Code

Fail Pass

Source Code
Fail Pass
Test
Domain VI - Problem detection and resolution >
Resolving Problems
T&T
RISK BASED SPIKE
• Risk based spike is a short proof of concept exercise that the team
undertakes to investigate an issue.
• It is a short experiment to investigate risks related to the project.
• On software project risk based spikes are undertaken to test new
technologies early in the project before proceeding too far with
development.
• E.g. Questions like “can we interface with a legacy system from a mobile
device?” would be investigated before proceeding with the project.

436
RISK BASED SPIKE

437
Domain VI - Problem detection and resolution >
Resolving Problems
T&T
FREQUENT VERIFICATIONS AND VALIDATION
• Frequent verifications and validations help in determining if things are
going as they should.

This shows the time taken for

verification at different level.
For example at the pair
programing level it takes just
a few seconds to spot any
Cost error, whereas at release
level it may take months to
detect an error.
 Validation vs Verification
• Validation: (usually external) the assurance that a
product, service, or system meets the needs of the
customer

• Verification: (usually internal of team) the evaluation

of whether or not a product, service, or system
complies with a regulation, requirement,
specification, or imposed condition

439
 Domain VI - Problem detection and resolution
> Resolving Problems T&T

TEST-DRIVEN DEVELOPMENT (TDD) / TEST-FIRST DEVELOPMENT (TFD)

• Test-driven development (TDD) and Test-First Development (TFD) are
techniques used in software development.
• The philosophy behind TDD is that test should be written before the
code is written.
• This means that developers should first think how the functionality will
be tested before they start to develop it.
• With TDD the developers will begin a cycle of writing code and running
the tests until the code passes all the tests.
• Then if required they will clean up the design to make it easier to
understand without changing the code’s behavior. This process is called
“refactoring”.
• Color codes used are Red for Fail, Green for Pass and Refactor or clean
for refactoring.
440
TDD and TFD

Key benefits are that

the teams thinks
about the tests that
the functionality
should pass for it to
work.
This ensures that
when the release is
taken out it, it is
already tested.

441
Domain VI - Problem detection and resolution >
Resolving Problems K&S
Level-1

PROBLEM SOLVING
• Agile methods encourages engaging the team in identifying, diagnosing
and solving problems.
• There are 3 steps to problem solving
1. Gather data – Data gathering helps in shared view of the problem.
Various techniques can be used such as Timeline in which the
participants write what they perceive about the problem on sticky
notes and put them on a white board in timelines.
2. Generate insights – This step is for analyzing the data. Techniques
include Brainstorming and 5Whys.
3. Decide what to do – At this stage the team decides what to do. One of
the Technique used is SMART (Specific, Measurable, Attainable,
Relevant, Timely) goals in which the goals are defined to resolve the
issue.
442
 5 Whys
• The Five WHYs a systematic approach to analyzing and identifying the root
cause of a problem / cause-and-effect for the problem or issue
• perform by repeatedly asking the question “Why” for at least 5 times until
the root cause has been identified
• imaginary example: Looking for the root cause for failing the PMI-ACP®
Exam
– Why did I fail the PMI-ACP® Exam?
– Because I got a lower mark than the passing mark
– Why did I get a lower mark?
– Because I was not sure about the answers to many questions.
– Why was I not sure about the answers to many questions?
– Because I could not remember some facts for the exam.
– Why couldn’t I remember some facts for the exam?
– Because I was not familiar with the PMI-ACP® Exam content.
– Why was I not familiar with the PMI-ACP® Exam content?
– Because I did not spend enough time revising the PMI-ACP® Exam notes.

443
 Fishbone Diagram
• Another tool for carrying out cause and effect analysis to
help discover the root cause of a problem or the bottle-
necks of processes
• aka cause and effect diagrams/Ishikawa diagrams
• to use Fishbone diagram technique:
– write down the problem/issue as the “fish head” and draw a
horizontal line as the “spine” of the fish
– think of major factors (at least four or above) involved in the
problem/issue and draw line spinning off from the spine
representing each factor
– identify possible causes and draw line spinning off the major
factors (your diagram will look like a fishbone now)
– analyze the fishbone diagram to single out the most possible
causes to carry out further investigation

444
Fishbone Diagram

445
Questions/Answers
Test
 Domain VII
Continuous Improvement

448
Domain IV Domain V Domain VI Domain VII

Team Problem Detection, Continuous

Adaptive Planning
Performance Resolution Improvement

Team Formation Levels of Planning

3 Tasks 5 Tasks 6 Tasks
2 Tasks

Team Adaptation
Empowerment 2 Tasks
3 Tasks

Team
Agile Sizing &
Collaboration &
Estimation
Commitment
5 Tasks
4 Tasks

10 tasks
9 tasks
449
Domain VII - Continuous Improvement
6 TASKS
Task 1:
– Tailor and adapt the project process by periodically reviewing and integrating
team practices, organizational culture, and delivery goals in order to ensure
team effectiveness within established organizational guidelines and norms.
Task 2:
– Improve team processes by conducting frequent retrospectives and
improvement experiments in order to continually enhance the effectiveness
of the team, project, and organization.
Task 3:
– Seek feedback on the product by incremental delivery and frequent
demonstrations in order to improve the value of the product.
Task 4:
– Create an environment of continued learning by providing opportunities for
people to develop their skills in order to develop a more productive team of
generalizing specialists.
450
Domain VII - Continuous Improvement
8 TASKS
Task 5:
– Challenge existing process elements by performing a value stream analysis
and removing waste in order to increase individual efficiency and team
effectiveness.
Task 6:
– Create systemic improvements by disseminating knowledge and practices
across projects and organizational boundaries in order to avoid re-
occurrence of identified problems and improve the effectiveness of the
organization as a whole.

451
Domain VII - Continuous Improvement

Practice Tool/technique Knowledge/skill

Continuous improvement ➢ Retrospective ➢ Knowledge sharing (L-1)
practices ➢ Process tailoring ➢ Principles of systems thinking (L-3)
➢ Process analyses (L-2)
➢ Applying new agile practices (L-2)
➢ PMI code of ethics (L-2)
➢ Continuous improvement
processes (L-2)
➢ Self-assessment (L-2)

452
Domain VII - Continuous Improvement >
Continuous Improvement Practices

453
 Domain VII - Continuous Improvement >
Continuous Improvement Practices T&T
RETROSPECTIVES
• A retrospective is a special meeting that takes place after each iteration.
• The objective of the meeting is inspect and improve methods and
teamwork.
• The lessons and improvements that result from them are applied in
subsequent iterations.
Total
• The retrospective process has 5 stages. 120 min

10-15%
15-20% 20 min
20 min
20-30%
30-50% 25 min
5% 40 min
6 min 454
 Domain VII - Continuous Improvement >
Continuous Improvement Practices T&T
RETROSPECTIVES
Brainstorming.
5 Whys.
Fishbone Plus/Delta
Helped/Hindered/
hypothesis
Getting ROTI – Return on time
people ready Create a invested
to participate. shared picture Short subjects. Appreciations
Outline the of the SMART goals
approach. problems or
Getting the issues.
people in the
mood to talk.

10-15%
15-20% 20 min
20 min
20-30%
30-50% 25 min
5% 40 min
6 min 455
 Domain VII - Continuous Improvement >
Continuous Improvement Practices
K&S
KNOWLEDGE SHARING Level-1

• Knowledge sharing is a key component of agile methods

• Knowledge sharing can be from team to customer and from
customer to team.
• Knowledge sharing happens at many levels through various
ceremonies (iteration planning meetings, daily stand-ups, review,
retrospectives).
• Knowledge sharing is also done through co-location of the team
through osmotic communication.

456
 Domain VII - Continuous Improvement >
Continuous Improvement Practices T&T

PROCESS TAILORING
• Processing tailoring is customizing processes to suite business
requirements.
• Scrum and XP do not encourage process tailoring, however Kanban can
be tailored to include other areas.
• While process tailoring take the following into account:

1. Get used to the normal agile methods before attempting to change it.
2. Carefully examine the motivation, to drop, amend, or append a
practice before changing it.

457
 Domain VII - Continuous Improvement >
Continuous Improvement Practices
K&S
Level-2
PROCESS ANALYSES
• Process analyses is closely relate to process tailoring. It is used
analyzing Agile methods to determine if they require any tailoring.
• While analyzing points to consider are to select that process that
are “heavy, intolerant, untried, etc.
• If the processes are successful the project will get shipped and the
people on the project will work in the same way again.

458
 Domain VII - Continuous Improvement >
Continuous Improvement Practices
K&S
CONTINUOUS IMPROVEMENT PROCESSES Level-2

• Continuous improvement is an on-going process.

• It is never completed, but it goes on throughout the project.
• The cycle is similar to Deming's cycle of plan > do > Check > Act

459
 Domain VII - Continuous Improvement >
Continuous Improvement Practices
K&S
Level-2
SELF ASSESSMENT

Self assessment is a standard

practice for the team to
reflect on itself to see what
it is doing and how well they
it is being done.

Self assessment scoring

model can also be used for
self assessment.

460
Testing (Exploratory and Usability)
• Exploratory testing
– seeks to find out how the software actually works,
– and to ask questions about how it will handle difficult and
easy cases by asking test subjects to try the software

• Usability testing
– a special type of exploratory testing with emphasis on the
usability of the software interface
– whether the test subject will be able to perform core tasks
on the interface without instructions and help

461
Testing (Exploratory and Usability)
• Help to provide insights on the design of the
software:
– Users’ expectations / habits
– Users’ ability to understand / comprehend the design of
the interface
– Users’ value of the functions of the software

• Both will provide valuable feedback early in the

project to enhance value delivery and avoid failure
later on

462
 Intraspectives
• intra = inside / within (per)spective = a particular way
of viewing things / inspection: intraspective
= inspecting within / seeing inwardly

• Intraspectives in Agile project management is an ad

hoc discussion / meeting by the Agile team to review
on the team practices or teamwork during the sprint,
often called for when something went wrong

463
 PreMortem
• A premortem is the hypothetical opposite of a postmortem in
which team members are asked to generate plausible
reasons for the project’s assumed failure.

• To make it safe for team members to voice out their

reservations about the plan / project direction / etc.

• Can identify possible causes of failure which are missed

during risk analysis

464
465
Questions/Answers
Test
End
Thank you

469