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