PMI-ACP Sample Course

Agile Project Management PMI-ACP速 Exam Prep Course Agile project management is in growing demand. This course is design for educational/training institutes, schools, colleges, organizations or individual consultants that would like to offer PMI-ACP速 training services. The Instructor and student manual are designed from PMI suggested reference materials and covers complete course outline defined in the PMI provided PMI-ACP速 examination content outline.

PMI-ACP速 Prep Course

Page 2

PMI-ACP® Prep Course

© 360PMO Project Management Consulting Inc. All registered and unregistered trademarks (service marks, brands, icons, copyright etc.) mentioned on in this document are the property of their respective owners.

PMI-ACP® Exam Prep Course is designed

By Aleem Khan, PMI-ACP, PMP, CSM

“PMI-ACP”, “PMI-Agile Certified Practitioner (PMI-ACP),” “PMOBOK,” “PMI,” and “PMP” are either marks or registered marks of the Project Management Institute, Inc.

360PMO Project Management Consulting, Inc. Phone: (416) 887-1618 Email: Info@360pmo.com Web:www.360pmo.com

Page 3

PMI-ACP® Prep Course

TABLE OF CONTENTS

LAYING THE GROUNWORK

SCRUM

Introduction and overview PMI® and PMI-ACP® Traditional vs. Agile Approach Agile Value & Principles Manifesto for Software Development Iron Triangle vs. Agile Triangle Planning in Agile Projects

What is Scrum?

Scrum Origins Scrum Legs/ Three Pillars Scrum Cycle Summary Scrum team -Roles of Scrum Team Scrum Events/Ceremonies Scrum Artifacts

LEAN DEVELOPMENT

EXTREME PROGRAMMING (XP)

Kanban Cards, Board and Process Core Principles Key Differentiators

What is XP? Values, Principles, & Practices The XP Team, Roles The Theory of Constraints

OTHER AGILE METHODS Crystal DSDM Kano Model

USER STORIES User Stories Defined 3 C’s INVEST Epic, story and theme Story writing workshop Acceptance criteria Acceptance test How User Stories are different from Use Cases Traditional requirements (functional/nonfunctional)

Page 4

PMI-ACP速 Prep Course

TABLE OF CONTENTS (continue)

PRODUCT BACKLOG

AGILE ESTIMATION

What is Product Backlog?

Ordered, Estimable, Emergent and Gradually Refined Ordering the Product Backlog Definition of Done (DoD) Definition of Ready (DoR)

What to Estimate Story Point & Ideal Time How do we Estimate Relative Sizing Wide Band Delphi Planning Poker Estimating Games Affinity Estimates

AGILE METRICS

AGILE TESTING

Velocity Burn-up/down chart

Traditional Testing How Traditional Testing Practices Evolved Traditional & Agile Testing Contrasted Exploratory Testing

OTHER AGILE KEY CONCEPTS

REVIEW

Retrospective Osmatic communication Continuous improvement Value delivery analysis/optimize the value stream Value based decomposition Minimal Marketable Feature (MMF) Escape Defect Decision Models

Review of Tools and Techniques Review of Knowledge Areas Review of Domain and Task

FLASHCARDS

RECOMMENDED RESOURCES

Key Agile definition and terminologies

Free internet resources, article, forums & groups

COURSE SUMMARY

EXAM TAKING TIPS

Page 5

PMI-ACP® Prep Course

User Stories Learning Objectives: • • • • • • • •

User Stories Writing style with example 3 C’s INVEST Epic, story and theme Story writing workshop Acceptance criteria, acceptance test and definition of done How User Stories are different from Use Cases, or traditional requirements (functional/nonfunctional)

Page 19

PMI-ACP® Prep Course

What are User Stories?

• •

User Stories are a great way to represent Product Backlog item Why User Stories? o Guide the development team with concise, right to point statements o Help keep backlog item aligned with the product vision o Provoke the product owner/customers to make a deep reflection while writing them o Invites development team and product owner/customers for conversation about the product

Page 20

PMI-ACP® Prep Course

3 C’s of User Stories

Figure 3.1 3 C’s of User Stories

Card: Story Description, enough to identify the requirement and to remind of what the story is about Conversation: Conversation about the story carried out between the development team and the customer & product owner. It is exchange of thoughts, opinion and feeling Confirmation: Tests that document the details of the story and is used to establish that the story is done .

Acceptance test The Card may be the most visible manifestation of a user story, but it is not the most important. Cards represent customer requirements rather than document them. This is the perfect way to think about user stories: While the card may contain the text of the story, the details are worked out in the Conversation and recorded in the Confirmation.

Page 21

PMI-ACP® Prep Course

INVEST To create good stories we focus on six attributes Bill Wake, author of Extreme Programming Explored and Refactoring workbook, has suggested the acronym INVEST for these six attributes (Wake 2003a).

Figure 3.2 3 six attributes of a good story

Independent: As much as possible, care should be taken to avoid introducing dependencies between stories.

Dependencies between stories lead to prioritization and planning problems. For example, suppose the customer has selected as high priority a story that is dependent on a story that is low priority.

Dependencies between stories can also make estimation much harder than it needs to be Mike Cohn in his book ‘User Stories Applied: For Agile Software Development’ suggest two ways to handle dependency in two ways 1. Combine the dependent stories into one larger but independent story 2. Find a different way of splitting the stories

Negotiable: Stories are negotiable. They are not written contracts or requirements that the software must implement.

Story cards are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team. Because story cards are reminders to

Page 22

PMI-ACP速 Prep Course

Agile Games for Instructors Games # 4: Test Driven Development Timing: 30 minutes Requirements: Supplied for each team 1.

2.

3.

4.

A4 Size Sheet Construction paper Rulers Scissors Markers

Page 43

PMI-ACP® Prep Course

Figure 5.3 Sample balloon requirement diagram

Instructions for Round 1: • • • • • • • • •

Draw figure 5.3 sample balloon requirement diagram on board and ask students to discuss the requirement.

They can ask any question in 2 minutes before they begin their first 1 minute long sprint.

Make sure team members work as a team.

The work is assign to team not to individual Most of your response should be ‘I don’t know’ or ‘what do you think type of statements.

Aim is to convince student that show something before providing further feedback Ask them to create/draw as many balloons they can in 1 minutes Review and reject (waste) Check each team Velocity

Page 44

PMI-ACP® Prep Course

Figure 5.4 Sample balloon requirement diagram

Instructions for Round 2: • • • •

• • • •

Before the second round, give the teams 2 minutes to discuss (retrospective) How they can improve for the next iteration.

Team should start asking more questions about the acceptance criteria, which you will happily offer.

When round 2 starts, draw figure 5.4, the teams will now apply the acceptance criteria to their work and some will even start building ‘test harnesses’ (e.g. paper templates for face, quick ways to measure balloon width, etc.) .

The results should be better in round 2.

Discuss how they changed the way they worked and what improvements they would make the next time.

If needed, play one more round. This time, every team should be using a test harness And should therefore be producing balloons with much more efficiency and quality.

Page 45

PMI-ACP® Prep Course

Key Learning Points: •

Defining acceptance criteria is not the same as writing tests, only to be applied after something is produced. They can be used as requirements, as tests, and as a target for developers.

•

Automating acceptance tests (or executable requirements) can be very useful, as demonstrated by the test harnesses produced during the game.

•

The investment in creating and automating acceptance tests is worthwhile and has a high return.

Source: “99 Test balloons", accessed on May 25, 2013, http://tastycupcakes.org/2009/06/99-testballoons/

Page 46

PMI-ACP® Prep Course

Exploratory Testing Exploratory Testing is: Simultaneously learning about the system while designing and executing tests, using feedback from the last test to inform the next

“Exploratory Testing” is a style of testing in which we learn about the behavior of a system by designing a small test, executing it immediately, using the information gleaned from the last test to inform the next.

We continue that rapid cycle of design a test, execute it, observe until we've characterized the capabilities and limitation with respect to charter or system Designing – Executing – Observing/Learning A style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of his or her work by treating test design, test execution, test result interpretation, and test-related learning as mutually supportive activities that run in parallel throughout the project.

IS NOT “random testing” (or sloppy, or slapdash testing)

IS “ad hoc”, in the dictionary sense, “to the purpose”

IS NOT “unstructured testing”

IS structured and rigorous

IS NOT procedurally structured

IS cognitively structured

IS NOT un-teachable

IS highly teachable

IS NOT unmanageable

IS highly manageable

IS NOT scripted

IS chartered

IS NOT a technique

IS an approach

Page 139

PMI-ACP速 Prep Course

Scripted vs. Exploratory Testing Scripted Testing

Exploratory Testing

Is directed from elsewhere

Is directed from within

Is determined in advance

Is determined in the moment

Is about confirmation

Is about investigation

Is about controlling tests

Is about improving test design

Emphasizes predictability

Emphasizes adaptability

Emphasizes decidability

Emphasizes learning

Like making a speech

Like having a conversation

Like playing from a score

Like playing in a jam session

Page 140

PMI-ACP速 Prep Course

Key Agile Terminologies Activity 1. A Scrum practice that involves taking action or performing a process, for example, sprint-planning activity, daily scrum activity, sprint review activity, and sprint retrospective activity.

2. In a general sense, the work performed by the Scrum team members such as writing code, performing tests, creating estimates, and so on Adaptation One of the three pillars (Transparency, Inspection and Adaptation) of empirical process control; feedback is used to make an adjustment to the work product being developed or the process by which it is being developed.

Affinity Estimating Affinity Estimating is a technique many teams use to quickly and easily estimate (in Story Points) a large number of user stories. This is a great technique if you're just starting a project and have a backlog that hasn't been estimated yet.

Agile 1. 1. A specific set of values and principles, as expressed in the Agile Manifesto (Beck et al. 2001).

2. 2. An umbrella term used for a group of related approaches to software development based on iterative and incremental development. Scrum is an agile approach to development Artifacts A tangible by-product produced during product development. The product backlog, sprint backlog, and potentially shippable product increment are examples of Scrum artifacts Burn-down chart A graph that shows on the vertical axis the quantity of work (in either hours or product backlog item units) remaining over time, which is shown on the horizontal axis. Because less and less work should remain over time, the general trend in the graph is to burn down to a point where no work remains. We can show projected outcomes on burn-down charts by calculating a trend line to see when work might be completed. Contrast with burn-up chart Burn-up Chart A graph that shows the progress of work toward a goal line associated with a value on the vertical axis. As work is completed over time (the horizontal axis), the progress line moves up (burns up) to be nearer to the goal line. We can show projected outcomes on burn-up charts by calculating a trend line to see when work might be completed. Contrast with burn-down chart.

Ceremony A ritualistic or symbolic activity that is performed on well-defined occasions. Some people refer to the core Scrum activities of sprint planning, daily scrum, sprint review, and sprint retrospective as ceremonies

Page 193

PMI-ACP速 Prep Course

Commitment The act of binding oneself to a course of action. Scrum encourages commitment. Commitment means that during both good times and bad, each team member is dedicated to meeting the team's collective goal. Contrast with forecast.

Complex Adaptive System A system with many entities interacting with each other in various ways, where these interactions are governed by simple, localized rules operating in a context of constant feedback. Examples include the stock market, the brain, ant colonies, and Scrum teams.

Component Team A team that focuses on the creation of one or more components of a larger product that a customer would purchase. Component teams create assets or components that are then reused by other teams to assemble customer-valuable solutions. Contrast with feature team.

Conditions of Satisfaction The conditions under which a product owner would be satisfied that a product backlog item is done.

Conditions of satisfaction are acceptance criteria that clarify the desired behavior. See also acceptance criteria.

Confidence Threshold 1. The definition of done for envisioning (product-level planning).

2. The set of information that decision makers need in order to have sufficient confidence to make a go/no-go funding decision for more detailed development.

Continuous Delivery/Continuous Deployment Deploying each new feature to users immediately after it is built, integrated, and tested. Synonymous with continuous delivery, integration.

Cumulative Flow Diagrams Cumulative Flow Diagrams. A project reporting area graph that shows work to do, work in progress and done.

Cross-functional Team A team composed of members with all the functional skills (such as UI designers, developers, testers) and specialties necessary to complete work that requires more than a single discipline.

Continuous Integration A technical practice where members of a single team or multiple teams integrate their work as frequently as is practical. See also integration, technical practices.

Daily Scrum A synchronization, inspection, and adaptive planning activity that a development team performs each day. This core practice in the Scrum framework is time-boxed to no more than 15 minutes. Synonymous with daily stand-up.

Page 194

PMI-ACP速 Prep Course

Daily Stand-up A common approach to performing a daily scrum whereby the participants stand for the entirety of the activity. Standing up promotes brevity and helps ensure that the activity does not exceed its timebox.

DEEP An acronym coined by Roman Pichler and Mike Cohn for remembering a set of criteria used to evaluate the quality of a product backlog. The criteria are detailed appropriately, Emergent, Estimated, and Prioritized Definition of Done (DoD) 1. A checklist of the types of work that the team is expected to successfully complete by the end of the sprint, before it can declare its work to be potentially shippable. A bare-minimum definition of done should yield a complete slice of product functionality, one that has been designed, built, integrated, tested, and documented and will deliver validated customer value.

2. Sometimes described as the acceptance criteria that apply to all product backlog items. Contrast with definition of ready.

Definition of Ready (DoR) A checklist of conditions that must be true before a product backlog item is considered ready to pull into a sprint during sprint planning.

Development Team A self-organizing, cross-functional team of people who collectively are responsible for all of the work necessary to produce working, validated assets. One of the three roles that constitute every Scrum team.

Dot Voting: A technique that allows participants to vote their preferences among a set of items by placing a colored dot on items that they believe are higher priority than other items. Items with more dots are higher priority than items with fewer dots. This technique is frequently used during the sprint retrospective activity.

Empirical process control A style of work that leverages the principles of inspection, adaptation, and transparency. Contrast with defined process.

Epic A large user story, perhaps a few to many months in size that can span an entire release or multiple releases. Epics are useful as placeholders for large requirements. Epics are progressively refined into a set of smaller user stories at the appropriate time.

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

Estimation A rough calculation of the value, number, quantity, or extent of something. In Scrum, we estimate the size of portfolio backlog items, product backlog items, and sprint backlog tasks.

Page 195

360PMO is the leading provider of Project Management Training and specializes in agile mentoring and coaching worldwide.

• Our business is built on long standing partnership with our clients • Our commitments are efficiency, reliability, and providing the highest service quality Order now for our PMI-ACP® Instructor and Student Courseware OR for further information please contact us at info@360pmo.com

360PMO Project Management Consulting Inc. Phone: (416) 887-1618 Email: Info@360pmo.com Web: www.360pmo.com