… à l'Ecole de la V.I.E …

Agile frequent verification and validation

Any iteration in agile development must produce artefacts, typically code, that pass the phase of verification and

validation.

Therefore, all iterations must have phases like this.

For requirements and design, the verification and validation is the result of peer reviews with team members and

with the customer

For coding, verification and validation is done by code reviews, unit testing and functional testing.

Basics of verification

Am I building the right product

Determining if the system complies with the requirements and performs functions for which it is intended and

meets the organization’s goals and user needs. It is traditional and is performed at the end of the project.

Am I accessing the right data

High level activity

Performed after a work product is produced against established criteria ensuring that the product integrates

correctly into the environment

Determination of correctness of the final software product by a development project with respect to the user needs

and requirements

Basics of validation

Am I building the product right

The review of interim work steps and interim deliverables during a project to ensure they are acceptable. To

determine if the system is consistent, adheres to standards, uses reliable techniques and prudent practices, and

performs the selected functions in the correct manner.

Am I accessing the data right (in the right place; in the right way).

Low level activity

Performed during development on key artefacts, like walkthroughs, reviews and inspections, mentor feedback

Demonstration of consistency, completeness, and correctness of the software at each stage and between each stage

of the development life cycle.

Importance of Verification and Validation in Agile

An Agile Methodology does NOT mean that there will be « frequent changes in requirements. »

What Agile specifically does is to begin with very high level view of the requirements at commencement, and

through the iterative process to begin honing those requirements with your stakeholders as they begin to interact

with the product itself.

 

Agile Continuous Integration

 

Continuous Integration is a software development practice where members of a team integrate their work

frequently, usually each person integrates at least daily – leading to multiple integrations per day.

Each integration is verified by an automated build (including test) to detect integration errors as quickly as

possible.

Many teams find that this approach leads to significantly reduced integration problems and allows a team to

develop cohesive software more rapidly.

Integration is often one of the most difficult moments in software projects.

In traditional waterfall development, the integration phase at the end of development can take a lot of time and reveal many design deficiencies.

Things become easier if the organization adopts the practice of bi-weekly, weekly, or daily builds.

The more frequently the system is built, tested, and verified, the earlier problems and deviations are found.

As with many other Extreme Programming practices, Continuous Integration is taking a known good practice to the

extreme level.

If it is good to integrate often, let’s keep the code integrated always.

The idea is to run the build and automated tests (at least the fast ones) whenever somebody checks code into the

version control system.

Usually it is done in automated manner by a tool such as CruiseControl

Benefits of Continuous Integration

When CI works well, it helps the code stay robust enough that customers and other stakeholders can play with the

code whenever they like.

This speeds the flow of development work overall; as Fowler points out, it has a very different feel to it.

It also encourages more feedback between programmers and customers, which helps the team get things right

before iteration deadlines.

Practices of Continuous integration (CI)

Maintain a single source repository

Automate the build

Make your build self testing

Everyone Commits To the Mainline Every Day

Every Commit Should Build the Mainline on an Integration Machine

Keep the Build Fast

Test in a Clone of the Production Environment

Make it Easy for Anyone to Get the Latest Executable

Everyone can see what’s happening

Automate Deployment

 

Test driven development: TDD /Test first development

Test driven development TDD /Test first development

Extreme programming (XP) emphasizes Test driven development (TDD)

Test Driven Development is primarily a design technique with a side effect of ensuring that your source code is

thoroughly unit tested.

However, there is more to testing than this.

You’ll still need to consider other agile testing techniques such as agile acceptance testing and investigative testing.

In fact, in XP the acceptance tests for a user story are specified by the project stakeholder(s) either before or in

parallel to the code being written, giving stakeholders the confidence that the system does in fact meet their

requirements.

Why use TDD

A significant advantage of Test Driven Development is that it enables you to take small steps when writing software.

For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your

tests will be broken by defects that exist in the new code.

It is much easier to find, and then fix, those defects if you’ve written two new lines of code than two thousand.

The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in

smaller and smaller steps.

TDD tools

Following are some available tools to do TDD
Jmock
Junit
PHPUnit
TestNG
VBUnit
DocTest
GoogleTest
Selenium
PyUnit

 

Agile technical debt and escaped defects

Escaped Defects

Escaped Defects are those defects reported by the Customer from production that have escaped all software quality processes are represented in this metric.

Technical debt

Technical debt is the amount of Escaping defects at a time.

How proceed with Technical debt ?

Escaping defects should then be treated as ranked backlog work items, along with other project work items.

They should be prioritized high enough to resolve them within the next sprint or two and not accumulate a growing

backlog.

Technical debt  and metrics :

Watch the defect backlog as part of the project metrics.

A growing defect backlog is a key indicator that the team is taking on more new work than it can handle.

To be able to calculate that metric, it is important that in your defect tracking system you track:

• Affected version, version of software in which this defect was found.
• Release date, date when version was released

The calculation process:

• Find all versions that were already released
• For each version, find all defects that affected the version
• If defect creation date is after version release date then this defect is an escaped defect.
• Now count all those escaped defects.

Monitor Escaped defects :

It should be possible to monitor Escaped Defects Found in following dimensions :

• Affected version, to monitor metric value of any released version.
• Project/Product. To aggregated Escaped Defects Found over all released versions of the project or product.

 

Agile cycle time and lead time

Cycle time

Cycle time clock starts when work begins on the request, and ends when the item is delivered.

Cycle time is a more mechanical measure of process capability.

Cycle time is the time between two successive deliveries.

To improve Cycle Time

Reduce Number of Things in Process

Improve Average Completion Rate

Reduce rework

High visibility of blockers and active removal

Analysis to identify items that are too large.

Lead time :

Lead Time is the time between the initiation and delivery of a User Story.

How to calculate cycle time

Total Cycle Time = Number of things in process /Average Completion Rate

Example: 1 week = 4 Items / 4 per week

Cycle time vs Lead time

Lead time :

Lead Time is the time between the initiation and delivery of a User Story.

In our case it is the time a Story enters the Deployed stage minus the time the story has entered the Backlog stage.

Story 34 has entered the Backlog in day 4, and enters the Deployed stage on day 11;

Lead time equals 7 days (day 11- day 4).

Cycle Time :

Cycle time is the time between two successive deliveries.

In our case it is the time between two stories entering the last stage– Deployed stage

In this case, 34 enters the Deployed stage on day 11, then two days after, the next story– Story 37–enters the

Deployed stage;

Cycle time equals 2 days (day 13 – day 11).

 

Agile risk and spike

Risk based spike :

A spike solution, or spike, is a technical investigation. It’s a small experiment to research the answer to a problem.

For example, a programmer might not know whether Java throws an exception on arithmetic overflow.

A quick ten-minute spike will answer the question.

Why use spike?

Spikes, another invention of XP are a special type of story used to drive out risk and uncertainty in a user story or

other project facet.

Spikes may be used for a number of reasons:

Spikes may be used for basic research to familiarize the team with a new technology of domain

The story may be too big to be estimated appropriately and the team may use a spike to analyse the implied

behaviour so they can split the story into estimable pieces.

The story may contain significant technical risk and the team may have to do some research or prototyping to gain

confidence in a technological approach that will allow them to commit the user story to some future time box.

The story may contain significant functional risk, in that although the intent of the story may be understood, it is

not clear how the system needs to interact with the user to achieve the benefit implied.

Spike solutions

Spike solutions are a learning technique based on performing small, concrete experiments.

If something doesn’t work as expected, is it because your understanding of the technology is wrong?

Is it due to an unseen interaction with the production code or test framework?

Standalone spikes eliminate this uncertainty.

For stories that you can’t estimate accurately, an alternative to scheduling a spike story is to provide a high estimate.

This is risky, because some stories will take longer than your highest estimate, and some may not be possible at all.

Another option is to research problems by reading about the underlying theory and finding code snippets in books or online.

This is often a good way to get started on a spike, but the best way to really understand what’s going on is to create

your own spike.

 

Accounting for Agile Project Labor Costs

In order to understand the capitalization of agile development expenditures, we should return to the definition of an “asset” and “capitalization,”.

The three stages of an IT project can be applied to agile as well as waterfall-developed software projects.

Accounting

An asset is defined as a potential future economic benefit that the firm controls based on past transactions.

To capitalize is to record an expenditure as an asset rather than to treat it as an expense of the current period.

The following describes the three different stages for an agile-developed project :

1. The Preliminary Project Stage includes conceptual formulation, evaluation and final selection of alternatives. Generally, once technical feasibility and the business case analysis are completed, the project is ready for consideration for funding approval by a company representative with budget authority.

After approval, the project team participates in a kick-off, or project inception, to deepen their understanding of WHAT the customer needs and to ensure that they will deliver an economic benefit to the organization with a high-level release plan.

All costs are expensed at this stage.

2. In the Application Development Stage, the design of the chosen path, including software configurations and interfaces, marks the capitalization of project labor costs.

The team now moves from WHAT to HOW.

All work associated with designing, developing, coding, testing and installing of hardware are valuable features for the customer that can be capitalized.

The customer may even be an internal department which will indirectly benefit the company’s net cash flows in the future.

One exception at this stage is administrative overhead, training and manual data conversion which should be expensed.

3. The Post-Implementation / Operation Stage begins after the code is in production and after final customer acceptance, testing and stabilization are completed.

Typical activities in this stage include training, bug-fixing and maintenance.

The costs at this stage are expensed.

Comparison of Phases Waterfall versus Agile Software Development Methods

Waterfall project

Methodology / Phase :

• Preliminary (Expensed)

All customer requirements are documented, analyzed and determined technically feasible.

Business case has merit.

Financial resources are authorized by a company representative with budget authority.

High level customer requirements are determined technically feasible.

• Development : (Capitalized, except administrative overhead costs)

Design, coding and testing.

Customer is not engaged.

Projects are linear.

• Post-Implementation / Operation (Expensed)

Customer accepts or rejects the project in the final approval stage.

Agile project

Methodology / Phase :

• Preliminary (Expensed)

 

High level customer requirements are determined technically feasible.

Business case has merit.

Financial resources are authorized by a company representative with budget authority.

• Development : (Capitalized, except administrative overhead costs)

Design, coding, testing: requirements prioritized for the next iteration with feedback from the customer.

Customer highly engaged throughout.

Projects have multiple iterations, and each may re-prioritize the requirements.

• Post-Implementation / Operation (Expensed)

Customer has accepted each iteration throughout the project, eliminating the risk of rejection in the final approval stage.

Capitalizing software development expenditures

The impact of appropriately capitalizing software development expenditures can be significant, and has a number of

important benefits.

Conservative treatment of agile projects -expensing all costs- limits the use and extent of agile- developed software

projects.

Software development resources are expensive and often limited.

Appropriate capital allocation of these resources is important to the competitive health of the company, and also

ensures consistent reporting and capital allocation within management and across organizations for investors.

For more information about the Software Development Lifecycle, please review:

http://en.wikipedia.org/wiki/Systems_development_life-cycle#Complementary_to_SDLC

For more information about Waterfall SDLC please review methodology:

http://en.wikipedia.org/wiki/Waterfall_model

For more information about Agile Methods and SDLC, please review:

http://en.wikipedia.org/wiki/Agile_software_development

Agile project management vs Traditional project management

Agile is a Different Philosophy

Traditional project management :

• Plan what you expect to happen

• Enforce that what happens is the same as what is planned

– Directive management

– Control, control, control

• Use change control to manage change

– Change Control Board

– Defect Management

Agile project management :

• Plan what you expect to happen with detail appropriate to the horizon

• “Control” is through inspection and adaptation

– Reviews and Retrospectives

– Self-Organizing Teams

• Use Agile practices to manage change:

– Continuous feedback loops

– Iterative and incremental development

– Prioritized backlogs

 

Value stream mapping

What is « Value stream mapping » ?

• Not Just Agile tool
• Lean manufacturing technique
• Illustrates flow, queues
• Used to determine waste to be removed
• Focus on value adding

Value Stream Mapping Steps :

1. Identify product / service to improve
2. Create as-is value stream map
3. Identify delays, waste, and constraints
4. Create to-be value stream map
5. Develop roadmap to optimized state
6. Revisit the process in the future

Value Stream Mapping Example :

Create a Value Stream Map for buying a cake to eat with your friend to celebrate passing the ACP exam.

Step 1 – identify starting point of the process (who initiates it) and the end point (who gets the end result)

You ……………………………………………………………………………………………………You & Friend eat cake

Step 2 – Identify the high level steps, inventories, and queues through the process
You…Cake Selection…..Bakery counter….Payment….Unpack & slice…You & Friend eat cake

Step 3 – Identify any supporting groups and alternative flows
You…Cake Selection…..Bakery counter….Payment….Unpack & slice…You & Friend eat cake
…………………………………….Bakers                    Sales

Step 4 – Measure the value-adding and non-value-adding activities; calculate efficiencies; and identify waste, bottlenecks, and improvement actions
You…Cake Selection…..Bakery counter….Payment….Unpack & slice…You & Friend eat cake
……………………………………Bakers                    Sales
Value add :

You…Cake Selection…..Bakery counter….Payment….Unpack & slice…You & Friend eat cake

……………1 mn                    2 mn                    2 mn                        2 mn                    10 mn

None Value Add (waiting) :

You…Cake Selection…..Bakery counter….Payment….Unpack & slice…You & Friend eat cake

……………………………..4 mn                    6 mn                      15 mn                            5 mn

Total Cycle Time = Value Add Time + Non Value Add Time Total Cycle Time = 47 mn

Process Cycle efficiency = Total Value Add Time / Total Cycle Time

Process Cycle Efficiency = 17 mn / 47 mn = 36%

Value stream mapping process steps :

1. Identify product / service to improve
2. Create as-is value stream map
3. Identify delays, waste, and constraints.
4. Create to-be value stream map
5. Develop roadmap to optimized state
6. Revisit the process in the future

Waste :

See also Agile, Lean and waste

7 Forms of Waste

Waste 1 : Partially done work

Description : Work started, but not complete; partially can entropy

Example : Work waiting for QA, Requirements waiting for development

Waste 2 : Extra processes

Description : Extra work that does not add value

Example : Unused documentation, Unnecessary approvals,

Waste 3 : Extra features

Description : Features that are not required, or are thought of as nice to haves

Example : Gold plating, Technology features

Waste 4 : Task switching

Description : Multi-tasking between several different projects that have context-switching penalties

Example :People on multiple projects

Waste 5 : Waiting

Description : Delays waiting for reviews and approvals

Example : Waiting for prototype reviews, Waiting for document approvals

Waste 6 : Motion

Description : The effort required to communicate or move
information or deliverables from one group to another; if teams are not co-located, this effort may need to be greater

Example : Distributed teams, Handoffs

Waste 7 : Defects

Description : Defective documents or work products that needs correction

Example : Requirement defects, Impractical processes

Value stream mapping example

Identify the wastes.

You……..Cake Selection…………..Bakery counter……………Payment…………..Unpack & slice………….You & Friend eat cake
Bakers                             Sales

Value add :

1 mn                                 2 mn                               2 mn                        2 mn                                         10 mn

None Value Add (waiting) :

4 mn                                     6 mn                      15 mn                                5 mn

Create To-Be Value Stream Map

– Without the waste
( Phone the “Cake Caterer” and place an order for delivery )
( Removes Waiting and Travel time wastes )

You…..Call…..Cake Caterer…..Order Cake……Provide Credit Card Details…..Unpack & slice……..You & Friend eat cake

Order Taker           Order Taker

Value Add :

1 mn                      2 mn                              2 mn                                2 mn                                10 mn

None Value Add :
2 mn               1 mn                                               10 mn                          5 mn

Total Cycle Time = Value Add + Non value Add time

Total Cycle Time = 35m

Process Cycle efficiency = Total Value Add Time / Total Cycle Time

Process Cycle Efficiency = 17m / 35 = 49%

PMI-ACP certification exam overview

The PMI-ACP certification is intended for practitioners who work on Agile project teams but not just project managers.

The PMI-ACP certification :

• Measures a practitioner’s knowledge and skill in Agile principles, practices, tools, and techniques
• Covers multiple Agile methodologies
• Intended to cover use of Agile both in Information and Communications Technology (ICT) and outside
ICT

The Value of PMI-ACP ® :

• For practitioners, PMI-ACP ® helps:
o Demonstrate a level of professionalism in Agile principles, practices, tools and techniques
o Increase professional versatility in project management
• For organizations, PMI-ACP ® demonstrates a practitioner’s:
o Knowledge of Agile practices, which shows the practitioner has greater breadth and depth as a PM

PMI-ACP – Eligibility Requirements

Requirement Description : Educational Level Secondary degree (high school or equivalent) or higher
General Project

Experience : 2,000 hours working on project teams. These hours must be earned within the last 5 years. Note: a PMP will be accepted to fulfill these requirements.

Agile Experience : 1,500 hours working on Agile project teams. These hours are in addition to the 2,000 general practice hours. These hours must be earned within the last 3 years.

Agile Training : 21 contact hours; hours must be earned in Agile project management topics

Examination Tests knowledge of Agile fundamentals and ability to apply to basic projects

Maintenance : 30 PDUs/3 CEUs every 3 years in Agile project management
Note: hours would count toward PMP

Cost : $435 PMI member; $495 PMI non-member

The process :

Complete certification application
Submit certification application /
Initial review of application
Pay certification fee
Audit (if selected) of education
and experience documentation
Take examination / assessments

Exam Design Objectives

Test Agile project knowledge and application:
• Most projects
• Most of the time
• Some remote team members
Not another Scrum (or XP, FDD) exam
• Combines Agile, Lean, and Kanban
Meet Agile Alliance Exam Guidance
“…employers should have confidence only in certifications that are skill-based and difficult to achieve.”

Exam Content

Tools & Techniques

Things you should be able to do.
The exam tests your ability to apply them, often through “do,” “calculate,” or “identify what happens next” type questions

Knowledge & Skills

Things you should know.
The exam tests your understanding and recall of them through questions that assess the “how” and “why” of the topics being tested

The “Tools &Techniques” and “Knowledge & Skills” Are split into 6 Domains
1) Value Driven Delivery
2) Stakeholder Engagement
3) Boosting Team Performance
4) Adaptive Planning
5) Problem Detection & Resolution
6) Continuous Improvement

Tools & Techniques (50%)
Knowledge & Skills (50%)

 

PMI ACPism’s

Be aware of Exam Question Assumptions:
• Assume a small, dedicated team (7 plus or minus 2) rather than a large one
• Delivery Team includes scrum master BA, QA, developer, product owner
• Collaboration is always better than command control style management
• Face-to-face (co-location) is better than virtual
• A stable team establishes a predictable velocity
• Teams self-organize, self-govern, self-directed, make their own commitments
• Recognize you can’t know everything at the beginning of a project
• A software product can be delivered incrementally
• Questions are asked from the perspective of a team
• On the iron triangle, agile sets the time and cost, scope varies
• Terminology: Timebox, sprint (scrum), iteration (xp) are used interchangeably

Exam Taking Tips

1. Find the test centre ahead of time

2. Bring authorization letter & two forms of ID

3. Wear comfortable clothes

4. Bring snacks

5. You will be given scratch paper and pencils

6. Write down anything you are having trouble remembering

7. You will see one question on the screen at a time. You can answer a question and/or mark it to return to it later.

8. The exam does not adapt to your answers

9. Use deep-breathing techniques to help relax

10. Use all the exam time. Do not leave early unless you have reviewed each question twice.

11. Find the question in the question text then read the rest of the text. Determine what your answer should be, and then look at the answer options shown

12. Read all 4 choices and choose the BEST answer

13. Quickly eliminate answers that are highly implausible

14. There may be more than one “correct” answer to each question, but only one “BEST” answer

15. Watch out for choices that are true statements, but do not answer the question

16. Options that represent broad, sweeping generalizations tend to be incorrect, so be alert for “always,” “never,” “must,” “completely,” and so forth. Alternatively, choices that represent carefully qualified statements tend to be correct, so be alert for words such as “often,” “sometimes,” “perhaps,” “may,” and “generally.”

Samples Question

Questions fall into:
1. Application of Tools and Techniques
2. Recall of Knowledge and Skills
3. Situational questions

Question 1 :

“An agile team is planning the tools they will use for the project. They are debating how they should show what work is in progress. Of the following options, which tool are they most likely to select?”
A) User story backlog
B) Product roadmap
C) Task board
D) Work breakdown structure

Answer 1 : C) Task board

 

Question 2 :

The Agile Manifesto value “customer collaboration over contract negotiation” means
that:
A) Agile approaches encourage you not to focus too much on negotiating contracts, since most vendors are just out for themselves anyway.
B) Agile approaches focus on what we are trying to build with our vendors, rather than debating the details of contract terms.
C) Agile approaches prefer not to use contracts, unless absolutely necessary, because they hamper our ability to respond to change requests.
D) Agile approaches recommend that you only collaborate with vendors who are using agile processes themselves.

Answer 2 : B) Agile approaches focus on what we are trying to build with our vendors, rather than debating the details of contract terms.

Explanation : Valuing customer collaboration over contract negotiation means we look for mutual understanding and agreement, rather than spend our time debating the fine details of the agreement.

 

Question 3 :

Which of the following items is not a benefit associated with product demonstrations?
A) Learn about feature suitability
B) Learn about feature usability
C) Learn about feature estimates
D) Learn about new requirements

Answer 3 : C) Learn about feature estimates

Explanation: Product demonstrations provide the benefits of learning about feature suitability and usability, and they can prompt discussions of new requirements. They are not typically used to learn about feature estimates, however, since estimating is done during estimation sessions, rather than during demonstrations.

Question 4 :

An agile team is planning the tools they will use for the project. They are debating how they should show what work is in progress. Of the following options, which tool are they most likely to select?
A) User story backlog
B) Product roadmap
C) Task board
D) Work breakdown structure

Answer 4 : C) Task board

Explanation: Of the options presented, the best tool to show work in progress is a task board. The user story backlog shows what work is still remaining to be done on the project. The product roadmap shows when work is planned to be completed.
Work breakdown structures are not commonly used on agile projects.

 

Question 5 :

When using a Kanban board to manage work in progress, which of the following best summarizes the philosophy behind the approach?
A) It is a sign of the work being done and should be maximized to boost performance.
B) It is a sign of the work being done and should be limited to boost performance.
C) It is a sign of the work queued for quality assurance, which should not count toward velocity.
D) It is a sign of the work queued for user acceptance, which should not count toward velocity.

Answer 5 ; B) It is a sign of the work being done and should be limited to boost performance.

Explanation: A Kanban board shows work in progress (WIP), which represents work started but not completed. Therefore, the WIP should be limited and carefully managed to maximize performance. More WIP does not equal more output; in fact, it is quite often the opposite.

 

Question 6 :

As part of stakeholder management and understanding, the team may undertake customer persona modeling. Which of the following would a persona not represent in this context?
A) Stereotyped users
B) Real people
C) Archetypal description
D) Requirements

Answer 6 : D) Requirements

Explanation : Personas do represent real, stereotyped, composite, and fictional people. They are archetypal (exemplary) descriptions, grounded in reality, goal-oriented, specific, and relevant to generate focus. Personas are not a replacement for requirements on a project, however.

 

Question 7 :

Incremental delivery means that:
A) We deliver nonfunctional increments in the iteration retrospectives.
B) We release working software only after testing each increment.
C) We improve and elaborate our agile process with each increment delivered.
D) We deploy functional increments over the course of the project.

Answer 7 : D) We deploy functional increments over the course of the project.

Explanation : Incremental delivery means that we deploy functional increments over the course of the project. It does not relate to retrospectives, testing, or changes to the process, so the other options are incorrect, or “less correct”.

 

Question 8 :

To ensure the success of our project, in what order should we execute the work, taking into account the necessary dependencies and risk mitigation tasks?
A) The order specified by the project management office (PMO)
B) The order specified by the business representatives
C) The order specified by the project team
D) The order specified by the project architect

Answer 8 : B) The order specified by the business representatives

Explanation: It is largely the business representatives who outline the priority of the functional requirements on the project. That prioritization is then a key driver for the order in which we execute the work.

 

Question 9 :

When managing an agile software team, engaging the business in prioritizing the backlog is an example of:
A) Technical risk reduction
B) Incorporating stakeholder values
C) Vendor management
D) Stakeholder story mapping

Answer 9 : B) Incorporating stakeholder values

Explanation : We engage the business in prioritizing the backlog to better understand and incorporate stakeholder values. Although such engagement will likely impact technical risk reduction, vendor management, or stakeholder story mapping, these are not the main reasons we engage the business.

 

Question 10 :

The steps involved in value stream analysis include:
A) Create a value stream map to document delays and wasted time, such as meetings and coffee breaks.
B) Create a value stream map of the current process, identifying steps, queues, delays, and information flows.
C) Review the value stream map of the current process and compare it to the goals set forth in the project charter.
D) Review how to adjust the value stream charter to be more flexible.

Answer 10 : B) Create a value stream map of the current process, identifying steps, queues, delays, and information flows.

Explanation : The only option here that is a step in value stream analysis is “Create a value stream map of the current process, identifying steps, queues, delays, and information

 

 

 

Question 11 :

What is the process cycle efficiency of a 2-hour meeting if it took you 2 minutes to schedule the meeting in the online calendar tool and 8 minutes to write the agenda and e-mail it to participants?
A) 90%
B) 8%
C) 92%
D) 96%

Answer 11 : C) 92%

Explanation : The formula for finding process cycle efficiency is: Total value-added time / total cycle time. In this question, the value-added time is 2 hours, and the total cycle time is 2 minutes + 8 minutes + 120 minutes = 130 minutes. So the correct answer is 120 / 130 = 92%.

Exam mark breakdown

 

PMI-ACP certification exam : formulas to know

Agile Manifesto Values :

If you don’t follow the four Agile Manifesto values “It Will Create Risks” or IWCR:

• I = Individuals and interactions over processes and tools
• W = Working software over comprehensive documentation
• C = Customer collaboration over contract negotiation
• R = Responding to change over following a plan

Agile Manifesto Principles :

Customer Satisfaction :

• Satisfy the customer by delivering software that provides value to the customer early, and often.

Welcomed Changes :

• It is expected that requirements will change and these changes are welcomed.

Frequent Delivery

• Get working software delivered to the customer as soon as possible.

Collocated Teams

• Bring the project team and the customers together, preferably collocated in the same physical area.

Motivated Individuals

• Build your team around motivated individuals and trust them to do the work.

Face-to-Face Contact

• Face-to-Face communication is the most effective method for exchanging
  ideas.

Working Software

• True customer value is realized by delivering results, which is represented in
  terms of working software.

Constant Pace

• Sustain a constant development pace to minimize project team burnout and maximize optimal performance indefinitely.

Continuous Attention

• Continuous Attention to technical excellence and good design will allow the project team to respond more quickly and easily to change.

Simplicity

• Maximize the amount of work not done.

Self-Organization

• The team decides how the tasks will be allocated, as opposed to being dictated
  to them.

Regular Reflection

• Schedule Retrospectives to constantly reflect on the work that was completed and find ways to improve during the next iteration.

Agile Manifesto Principles as Months

January : Just Sit Together (Collocated Teams)

February : Face-to-Face Contact (Face-to-Face Contact)

March : Motivated Individuals (Motivated Individuals)

April : Attention (Continuous Attention)

May : Maintain a Constant Pace (Constant Pace)

June : Jump on Improvements (Regular Reflection)

July : Juggle Changes (Welcomed Changes)

August : Augment Customer Satisfaction (Customer Satisfaction)

September : Simplicity (Simplicity)

October : Organization (Self-Organization)

November : New Changes (Welcomed Changes)

December : Deliver Frequently (Frequent Delivery)

User Stories

To ensure all user stories are effective, you need to “INVEST”:
 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable

Agile Iteration Events

For productive iterations, each team member should attend all meetings as a “PEER”.
 Plan each iteration (Iteration Planning)
 Expect daily updates (Daily Stand-Up)
 Examine product results (Iteration Review)
 Reinvent processes for next iteration (Iteration Retrospective)

Formulas :

Internal Rate of Return (IRR) N/A Select project with biggest IRR

Net Present Value (NPV) N/A Select project with biggest NPV

Return on Investment (ROI) N/A Select project with biggest ROI

Schedule Variance (SV) :

SV = EV – PV

< 0 is bad
= 0 is good
> 0 is good

Schedule Performance Index (SPI) :

SPI = EV / PV < 1 is bad
= 1 is good
> 1 is good

Cost Variance (CV):

CV = EV – AC < 0 is bad
= 0 is good
> 0 is good

Cost Performance Index (CPI):

CPI = EV / AC

< 1 is bad
= 1 is good
> 1 is good

PMI-ACP certification exam : points to know

What does MoSCoW stand for ?

« MoSCoW is a prioritization exercise techneque based upon putting features in the following categories:
Must Have.
Should Have this if it is possible to get.
Could Have this if it doesn’t impact anything else above.
Won’t have this time but would like to have in the future »

Name 3 ways Risk is managed in an agile project

« Risk Adjusted Backlog
Risk Burndown Graph
Risk Based Spikes »

Desribe a Risk Adjusted Backog

« A risk adjusted backlog takes into consideration the amonut of risk a feature or function (story) places on the overall project/product.

The goal in risk adjusting the backlog is to have a balance of value generating items and risk reduction items to maximize the value creation possible.

Risk reduction items may be avoidance, mitigation, or acceptance items.  »

What is EMV and how is it used in relation to backlog prioritization

« EMV is the Expected Monitary Value of an action, feature or function.

EMV is used to calculate the Expected value at risk for an item.
E.g. Risk % Value EMV
20% of $20000 = $4000 risk

This is used as input to the overall prioritization of the backlog.  »

Discuss risk based spikes

A Spike is a time boxed exploration of a feature or issue that is not clear enough to quantify.

Risk based spikes are used to explore a risk so that it is clear enough to make reasonable mitigation plans.

What are acceptable risk responses ?

« Avoid – Attempt to not encounter the risk condition
Mitigate – Make plans to minimize the impact of the risk condition
Transfer – Make someone or something else take the impact (e.g. outsourceing or insurance) of the risk
Accept – simply accepting that it is going to happen (e.g. if the risk impact is small) »

What is Cycle time ?

Cycletime is the time a system produces a new product.

It is measured by observation at the end of the system.

If a new car rolls off an assembly line every 5 minutes then cycle time is 5 minutes.

There is 5 miutes between cycles.

Discuss Throughput

« Throughput is the total time it takes to create a new product.

If a new car takes 3 weeks from start of production to delivery the total throughput time is 3 weeks.

Which is better and why? Online Charts or Big On the Wall charts?

« It is better to have charts on the wall if all of the team members are collocated.

Charts and metrics online need to be deliberatly accessed, a big chart up on the wall is easy to casually look at on your way to lunch or on a break.

If teams are distributed it is still a good idea to keep the charts up on the wall, in addition to online.  »

What metrics should be kept on an agile project?

As few as reasonably possible and no less. Metrics should include good measures (Stories completed) as well as bad (Bugs found)

What is the importance of the Running Tested Features metric?

« The running tested features metric directly shows progress, at any time duing the project.

By shoing how many features are passing all of their user acceptance tests at that moment.

Running: the features are integrated and functioning in production

Tested: the features are passing thier tests.

Features: End user features that bring direct customer value, not non-functional requirements.  »

What is the Observer effect?

« the observer effect is that the act of observing impacts the observation.

For example: testing to see if productivity improves in low or high light conditions.

The lights are dimmed, and productivity increases, the lights are brought back up and productivity still increases, it is found that productivity incrases becasue they were being given attention not due to the changing conditions.
Also known as the Observer-expecantcy effect.  »

What is confirmation bias?

Confirmation bias is the tendency of people to pay attention to facts and observations that confirm their existing beliefs and to ignore or explain away contraditiory information.

Discuss cargo cults.

« A Cargo Cult is a group of people who perform the activities that they have seen to produce good results by others, without understanding of why they produce good results. A cargo cult copies the actions but often does not receive the benefits of them because they do not understand the complete picture.

For example a team may assign story points to work but not understand how they work or why they are using them and thus never receive the full benefits of using them: dynamic schedule indicator, group ownership, team buildng, common understanding.  »

Discuss Agile EVM

« EVM is Earned Value Management.

A set of metrics that show cost performance and schedule performance against planned outcomes.

Agile EVM applies these techniques of measuring actual work vs. planned work and actual cost vs planned cost to determine if the project is on track or not.

Currently there is no standard way to apply Agile EVM.  »

Why are escaped defects an important metric for agile projects ?

« Escaped defects are defects that have slipped past all testing and made it into a production system.

Generally this should not happen.

It shows a flaw in the system somewhere: the test coverage, the testing process, or other systematic issues.  »

What is Value Stream Analysis

Value stream analysis is the process of evaluaing the process of turning raw materials into finished and delivered goods. In software this is from concept to delivery.

A Value Stream map idenfies each work process and any waiting or queue times

What is Waste?

Waste is any time in the value stream that does not directly add value to the product.

What is Type 1 Muda ?

Work that is non-value add but necessary for the current system to function.

What is Type 2 Muda ?

Work that is non-value add and may immediately be eliminated

Agile dictionary

Adaptive

– Frequently responding to changes and learning’s on a project by changing the plan, priorities, and/or approach.

Agilists believe changes are good!

Agile Methods

– A set of development methodologies characterized by being iterative, adaptive to changes and learning, value driven, low ceremony, and encouraging empowered teams.

BDUF

– Big Design Up Front is a condescending term given to large efforts invested early in the project to define requirements or design before building some functionality and getting feedback from the user community.

Burn Down Graph

– a project reporting trend graph popular in Scrum used to show the progressive reduction in features or estimated work remaining on the project.

Burn Up Graph

– a project reporting trend graph that shows the total number of stories (or features) delivered to date on the project.

Continuous Integration

– the process of building and testing the system upon the check-in of any code. Examples of continuous integration tools include: TeamCity and CruiseControl

CAPM

– Certified Associate in Project Management, a designation from the PMI given to project managers who have passed the CAPM exam which is easier and less demanding than the PMP exam.

CPI

– Cost Performance Index

– a measure of project progress from a cost perspective.

Agile projects can obtain the same metric by dividing the Planned Costs to date by the Actual Costs to date.

Critical Path

– In traditional project management, it is the longest path through the network of project tasks and dependencies.

In theory it defines the shorted time that the project can be completed in.

Its accuracy is driven by the quality of the task estimates which early in a software project could be very low.

Cumulative Flow Diagrams

– A project reporting area graph that shows work to do, work in progress, and done. Burn graphs and CFDs can replace Gantt charts to track progress

Agile projects can get the same information by tracking the features delivered

CV

– Cost Variance

– A measure of how much under or over budget we are.

Agile projects calculate this the same way as traditional projects: by deducting the amount actually spent from
the amount planned to be spent by now. (negative numbers mean you are over budget)

EV

– Earned Value

– The value of the work completed to date. .

EVA

– Earned Value Analysis

– the process of measuring project performance against the performance defined in a baselined plan.

For Agilists an issue is the accuracy of the baselined plan.

If that was flawed due to a poor understanding of the true requirements (common for SW) then why track progress against this faulty map.

DSDM

– Dynamic Systems Development Method – an agile method created by a consortium of representatives that promotes ideas such as agile suitability filters and agile contracts

Elaboration

– The PMBOK’s term for acknowledging that details will likely emerge as the project progresses and perhaps the plan will need amending. However,

It assumes that the differences will be small and easily accommodated into the plan.

Agile teams can you this concept to introduce more radical adaptation ideas.

FDD

– Feature Driven Development an agile method popularized by Jeff De Luca and others that values some upfront architecture and works well for larger projects

Feature

– A description of a business understandable and business valued piece of functionality.

The unit for prioritization, planning, estimation, and reporting.

Some agile methods use the term Story, or Prioritized requirement.

Gantt Chart

– Horizontal bar graph based depiction of project task durations and dependencies.

Thought by Agilists to be OK at a high level, but detached from reality for modeling detailed technical tasks.

IKIWISI

– I’ll Know It When I See It

– a mnemonic that described the need to see working software before being able to fully appreciate it’s fit for purpose and articulate the true business requirements.

Iteration

– A short, fixed time period (typically between 1 and 4 week) during which the team produce a potentially deployable release of software for evaluation. Scrum calls them Sprints.

Pair Programming

– the XP practice of two developers working at one PC to write and review code together.

Parking Lot Diagram

– a status reporting graph used in FDD to summarize project progress across a number of functional areas

PERT

– Program Evaluation and Review Technique – a network diagram based modeling technique used to determining likely project durations and identify critical path activities.

If done only at the start of a project it is thought by Agilists to suffer from premature specification issues.

Planning Game

– A facilitated workshop during which developers and business representatives estimate work tasks and plan upcoming iterations.

PMBok

– Project Management Body of Knowledge

– The PMI’s reference text of knowledge areas that project managers should understand.

The principle basis of the PMP exam.

PMI

– Project Management Institute

– A project management standards and certification body widely used in North America.

Creator of the PMBOK Guide and assigner of CAPM, PMP, PMI-ACP and others certifications.

PMO

– Project Management Office,

– a group responsible for centralizing project management best practices and assisting with best practice application.

Their actual roles will vary from organization to organization.

PMP

– Project Management Professional

– the designation given to project managers who have passed the PMI’s PMP Exam

PRINCE2

– Projects, IN, Controlled, Environments version2, a European based project management standards and certification body.

PRINCE2 is structured, but has less lifecycle guidance than the PMBOK Guide and so is generally easier to integrate agile methods within.

Prioritized Requirement

– A description of system functionality that has been prioritized by the business.

The unit for planning, estimation, and reporting.

Some agile methods use the term Story, or Feature.

Product Backlog

– The prioritized list of stories, features, or requirements that the project works it’s way through.

The closest thing to a list of requirements a traditional PM will find.

PSO

– Project Support Office, similar to a PMO, a group responsible for centralizing project management best practices and assisting with best practice application.

Their actual roles will vary from organization to organization.

Refactoring

– The process of improving code (by clean-up, simplification, etc) to make it easier to maintain and expand in the future. Refactoring is a necessary step to keep the cost of changes low.

Requirements Sign-off

– Formal sign-off on a requirements document to indicate that the requirements are complete and agreed.

Subsequent changes will require submission through a change management process.

Retrospective

– a facilitated workshop exercise held at the end of iterations and releases in which project stakeholders are asked to reflect back on the work to date and recall:

What has worked,

Areas for improvement, and

Suggestions for the future.

Similar to Lessons Learned sessions but performed throughout the project.

Rolling Wave Planning

-The PMBOK’s term for acknowledging that planning needs to be iterative and repeated throughout the project.

Agile teams can you this concept to help introduce iteration plans and reprioritization.

RUP

– Rational Unified Process an iterative methodology owned by Rational (IBM) that can be made to be agile through strict controls on the artifacts selected, but implemented by many organizations as a heavier than agile, iterative approach

Scrum

– An agile method popularized by Jeff Sutherland, Ken Schwaber and others employing 15 to 30 day Sprints (iterations) and minimalist controls.

ScrumMaster

– The iteration manager on a Scrum project.

Often performed by the project manager to team lead, the ScrumMaster is responsible for managing the iterative development process.

SPI

– Schedule Performance Index

– a measure of project progress from a timeline perspective.

Agile projects can obtain the same metric by dividing the # Completed Features by the # Planned Features.

SPI

– Software Process Improvement.

Spike

– A short focused period of development undertaken to prove new technology.

For example “We’ll spike the Oracle 10g compatibility”

Sprint

– an iteration, a period of time to undertake development.

In Scrum Sprints are typically 15 to 30 days in duration.

Standup meeting

– a short (15 minutes or less) daily meeting during which team members report on

What they accomplished since the last meeting,

What they plan to accomplish today, and

Report any impediments or blockers to making progress.

Story

– A shorthand requirements document that acts as a placeholder for further discussion and elaboration with a user representative to determine the true business requirement.

The unit for prioritization, planning, estimation, and reporting in XP.

Some agile methods use Features, or Prioritized requirements as their requirement units.

SV

– Schedule Variance

– A measure of how much ahead or behind schedule we are.

Agile projects can get the same information by deducting the number of features actually delivered from the number of features planned to be delivered by now.

TDD

– Test Driven Development.

The practice of writing tests first to better understand the requirements of new functionality.

The test fails and code is written until the test passes.

Traditional plan to Agile Baseline

– an approved and saved project plan used to compare progress against.

Velocity

– the rate of development progress.

Usually expressed as stories completed (and tested) per iteration.

The primary measure of development speed.

WBS

– Work Breakdown Structure – an org chart style, hierarchical breakdown of project
deliverables or functionality. If done very early or taken very deep in detail it may be considered
by agile teams as a form of BDUF

XP

– eXtreme Programming an agile method popularized by Kent Beck, Ron Jefferies, and others that promotes techniques such as pair programming and user stories.

YAGNI

– You Ain’t Going Need It

– an XP based mantra that reminds us to keep designs simple and do not over complicate solutions for potential future expansion that may never be required.

 

This Agile dictionary was wrottten by Mike Griffiths, an independent consultant specializing in effective project management.

Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum, FDD, XP, DSDM) for the last 13 years.

He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN).

He is also a contributor to the PMBOK and trainer for the PMI SeminarWorlds program.

He maintains a leadership and agile project management blog at www.LeadingAnswers.com

Learning the PMI-ACP certification exam

Tips to Prepare

Review the current PMI-ACP reference list.

Enroll in a formal study course.

Review self-study books published by reputable training organizations.

Communication elements :

Information Radiators

Team Space

Agile Tooling : a minimal Agile tools is necessary

Osmotic Communications

Daily Stand up Meeting

Planning monitorine and adapting :

Retrospectives

Task Board/Kanban boards

Time boxing

Iteration and release planning

WIP Limits

Burn up /Down Charts

Cumulative flow Diagram

Process tailoring

Increasing or decreasing process for the sake of the particular environment; e.g. CMMI or ISO9000 compliance.

Requires tradeoffs

Agile estimating :

Relative Sizing / Story Points
Wide Band Delphi / Planning Poker
Affinity Estimating
Ideal Time

Agile analysis and design :

Frequent Verification and Validation
Verification is verifying what was specified is being made. Performed during development.
Validation is checking what was made does what it was supposed to. More holistic than verification. Prove that it does what it was specified to do by audit trail.
TDD & Test First Development
Definition of Done
Continuous Integration

Soft skills :

Emotional Intelligence
Collaboration
Adaptive Leadership
Negotiation
Conflict Resolution
Servant Leadership

Value based prioritization :

ROI/NPV/IRR
Compliance
Minimally
Marketable Feature (MMF)
Relative Prioritization / Ranking

Risk management :

Risk Adjusted Backlog
Risk Burn Down Graph
Risk Based Spike

Metrics :

Velocity
Cycle time
Earned Value Management
Escaped Defects

Control limits :

The Agile PM needs to have a sense of the control limits to set expectations and guide the project.

It helps is to remember that Quality Assurance is about making sure your process is « in control ».

If the project violates certain limits, then the process is said to be « out of control ».

Below are some examples of when an agile project has exceeded various agile process limits:

WIP limits for Kanban

Scope changes within a Sprint

Delivering defects higher than the agreed upon maximum defect rate (e.g. violating the « no-defects » process limit)

When the actual trend on a burn down / burn up chart exceeds the ideal trend by a certain threshold (see Agile EVM)

Slipping an iteration deadline, rather than respecting it

Slipping the agreed-upon time box for ceremonies and spikes When velocity dips dramatically below recent trend lines

Lead/Cycle time policy by Class of Service to this list.

General Questions About Agile

Q1. What is agile?

Agile is a philosophy that uses organizational models based on people, collaboration and shared values. Agile uses rolling wave planning; iterative and incremental delivery; rapid and flexible response to change; and open communication between teams, stakeholders, and customers.

There are many approaches to agile that adhere to these tenets, such as Scrum, Extreme Programming (XP), Lean, Kanban and Test-driven Development (TDD).

Although agile principles have their roots in the software and IT industries, agile adoption is growing and expanding in a wide range of industries, including health care, marketing and manufacturing.

Q2. What are some examples of agile principles and practices?

Agile principles and practices include:

Early, measurable return on investment through defined, iterative delivery of product increments

High visibility of project progress allows early identification and resolution or monitoring of problems

Continuous involvement of the customer throughout the product development cycle

Empowerment of the business owner to make decisions needed to meet goals

Adaptation to changing business needs, giving more influence over requirement changes

Reduced product and process waste

Q3. What value do agile principles and practices bring to an organization?

Organizations who use agile principles and practices have documented the value they see from these techniques:

• Adaptive to changing business needs, giving the organization more influence over adding, changing or removing
requirements

• Early and continuous customer feedback improves communication and empowers business owners who can receive and review critical information necessary to make decisions to steer the project throughout the development process

• Early measurable return on investment

• High visibility and influence over the project progress leading to early indications of problems

• Incremental delivery rather than a single complete delivery at the end of the project reduces product and process waste

Passing the PMI-ACP certification exam

The PMI Agile Certified Practitioner (PMI-ACP)® formally recognizes your knowledge of agile principles and your

skill with agile techniques. It will make you shine even brighter to your employers, stakeholders and peers.

The PMI-ACP® is a fastest growing certification, and it’s no wonder.

Organizations that are highly agile and responsive to market dynamics complete more of their projects successfully

than their slower-moving counterparts — 75 percent versus 56 percent — as shown in 2015 Pulse of the Profession®

report.

The PMI-ACP spans many approaches to agile such as Scrum, Kanban, Lean, extreme programming (XP) and

test-driven development (TDD.) So it will increase your versatility, wherever your projects may take you.

Understand and apply agile tools, principles and practices on basic projects.

To earn the PMI-Agile Certified Practitioner (PMI-ACP)® certification, you must meet the experience and

education requirements, and pass the PMI-ACP exam, a 120-question, multiple-choice test.

3 hour computer based multiple choice exam offered at authorized Prometric Test Centres

120 multiple choice questions (4 choices, 1 correct answer)

(100 scoring questions, 20 test questions)

Exam = 120 questions in 3 hours

100 scored

20 unscroed

The PMI-ACP certification exam covers principles,practices and tools and techniques across agile methodologies

(Scrum, Kanban, XP, Lean, DSDM / AgilePM, TDD, ATDD and more).

The exam specification details the following percentage breakdown of exam questions by category:

Tools and Techniques (50%)

Knowledge and Skills (50%)

Tools and Techniques (50%)

Communications

Planning, monitoring, and adapting

Agile estimation

Agile analysis and design

Product quality

Soft skills negotiation

Value-based prioritization

Risk management

Metrics

Value stream analysis

Knowledge and Skills (50%)

Level 1 : 18 skills (33%)

Level 2 : 12 skills (12%)

Level 3 : 13 skills (5%)

Level 1 : 18 skills (33%)

Active listening

Agile Manifesto values and principles

Assessing and incorporating community and stakeholder values

Brainstorming techniques

Building empowered teams

Coaching and mentoring within teams

Communications management Continuous improvement processes

Feedback techniques for product (e.g., prototyping, simulation, demonstrations, evaluations)

Incremental delivery

Knowledge sharing

Leadership tools and techniques

Prioritization

Problem-solving strategies, tools, and techniques

Project and quality standards for Agile projects

Stakeholder management

Time, budget, and cost estimation

Value-based decomposition and prioritization

Level 2 : 12 skills (12%)

Building high-performance teams Agile project accounting principles

Business case development

Colocation (geographic proximity) / distributed teams

Continuous improvement processes

Elements of a project charter for an Agile project

Facilitation methods

Participatory decision models (e.g., input-based, shared collaboration, command)

PMI’s Code of Ethics and Professional

Self assessment

Value-based analysis

Level 3 : 13 skills (5%)

Agile contracting methods

Agile project accounting principles

Applying new Agile practices

Compliance (organization)

Control limits for Agile projects

Failure modes and alternatives

Globalization, culture, and team diversity

Innovation games

Principles of systems thinking (e.g., complex, adaptive, chaos)

Regulatory compliance

Variance and trend analysis

Variations in Agile methods and approaches

Vendor management

Broad Understanding of Agile and lean is required

Developed and independently validated by global groups of agile professionals

Intended to be industry agnostic

PMI-ACP elligibility prerequisites :

2000 hours Project
1500 hours Agile Experience (non-overlapping)
21 hours Agile Training : may be taught by anyone

Exam

It’s a Pass/Fail Exam

Exam administered by ProMetric

exam is preceded by a Tutorial

Questions 120

100 Scored

20 Pretest (unscored)

Time : 3 hours

No breaks

No materials

Followed by a Survey

Exam Results :

Proficient – Above Average level of knowledge

Moderately Proficient – At the average

Below Proficient – Below average

Exam pass percentage is NOT publicized

PMI-ACP certification

You must maintain Credential in 3 year cycles.

PMI-ACP credential holder will need to earn 30 PDUs in agile project management per three-year cycle.

PMI-ACP exam price

Member Computer: $335

Non-Member computer: $435

…/…