PMI Agile Certified Practitioner (PMI-ACP) ^SM Certification Study Tips

The PMI-ACP ^SM Certification is finally here and there is lots of BUZZ and interest surrounding it in the community which is very positive. I recently took the PMI Agile Certified Practitioner (PMI-ACP) ^SM certification exam myself and posted ‘My PMI-ACP ^SM Certification Exam Retrospective’ blog.  The goal from this particular post is to provide a little more guidance and detailed tips on key topics that were outlined in the exam guide but several folks from the community had questions surrounding them to help you as you prepare to take your own exam. Several members of the PMI-ACP^SM certification steering committee and Agile Community of Practice also plan to post guides on various topics.
Below is the list of topics shared by Dennis Stevens in addition to a few more. I have to say that your best source for information on the exam content will be the recommended reading books listed on the www.pmi.org/agile page. My attempt below is only to clarify areas of ambiguity as best I can but do not claim to have any definitive answers on what will be on the exam !

Agile Methods:

• Review the Agile Values and Principles thoroughly.
• Learn Scrum thoroughly! (Ken’s Agile Project Management with Scrum is the recommended book for this)
  • Understand the key roles and what they do.
  • Understand the Scrum artifacts such as product backlog and burn down charts. Know what they are, why we use them and how to analyze the charts.
  • Understand the Scrum meetings such as Sprint Planning, Daily Scrum, Sprint Review and Retrospective very well. You should know what happens in each of these meetings.
  • Learn and understand the basic Scrum Rules. For example, how do we handle a new requirement/story that the Product Owner introduces in the middle of a Sprint? Who can speak during the daily Scrum?
• XP (eXtreme Programming) – (James Shore’s Art of Agile Development is the recommended book)
  • Really understand the XP roles and who does what.
  • Understand the various XP practices. For example
  • Understand Test Driven Development, how it works and its value.
  • Understand Continuous Integration, how it works and its value.
• Lean  (Alan Shalloway’s Lean-Agile Software Development is the recommended book to read)
  • Understand the History of Lean and the Lean Software Development Principles
  • What is Lean Portfolio Management and what is the value of it to the organization?
  • Value Stream Mapping,  How to do it Video
  • Understand the basics of Kanban (what is it? can you mix it with other Agile methods? how prescriptive is it? what is WIP? how does the Kanban wall help us optimize our process flow?..)
• Learn the other Agile methods and what they are about. (Crystal, FDD, DSDM ..)

Osmotic Communication :

• Alistair Cockburn (author of Agile Software Development – The Cooperative Game) describes this as the information that flows in the background hearing of teams that are co-located so they pick up relevant information, as though by osmosis.
• When someone asks a questions then others can tune in or out and contribute to the conversation. This is an example of rapid and rich feedback that has high value with little structure. It can help the team identify and address errors, issues and risks early on the project.

Servant Leadership:

• Leaders understand that their role is to empower the team, help them make their own decisions, help them become self organizing and not use command and control to direct them. This is the hardest transition initially for traditional project managers (and leaders) if they were used to a command and control style of managing.
• The focus of servant leaders is the growth and empowerment of the people instead of the management of the tasks. Learn how you can transition to being the team’s coach, mentor and facilitator instead of their problem solver.
• I’m really passionate about this topic so we have a full 2 day course just on this subject!

Agile Risk Management:

Agile Planning and Estimation:

Communications Management:

• Planning: Identifying who you need to communicate to (Team members, Sponsor, Stakeholders) and what you need to communicate to them (Project and Team Charters, Release Plan, Iteration planning, daily standup, demo and retrospective meeting dates/location, team velocity, team task board or team room location, project portal site, etc.)
• Stakeholder Management: Setting clear expectations from the very start with your stakeholders on what information they need, how and when they should engage with the team and how frequently (time commitment needed for success), how do we communicate changes in scope/time/schedule to them, how do we communicate project risk.
• Performance Reporting and Visible Information Radiators: Understanding what information radiators are all about and why we use them, how to leverage their power even for distributed teams, how we track and report performance through burn up/burn down charts at the iteration level and at the release level. How we can analyze the various charts and understand if things are going well or not and respond quickly to what we’re seeing.

Project and Quality Standards:

• Quality is collectively owned by the team and no longer the sole responsibility of the testing team. The testers, analysts and developers all collaborate early on to define the quality measures for their project.
• Quality planning in Agile happens as part of the team’s Release Planning, Iteration Planning and daily planning activities.
• The team along with the product owner develops their ‘Definition of Done’ that provides clear guidance for when a ‘story’ is done.
• This could also be defined at various other levels, for example we could have a ‘Release  definition of Done’ and a ‘Project definition of Done’. The story definition of Done would contain the product owner’s expectations for quality and the team’s standards. For example, a team could decide a story is Done when:
  • There are no outstanding open defects/issues.
  • The code has been checked in to source control and tagged correctly.
  • Unit testing has passed with x% code coverage.
  • ‘Just Enough’ documentation has been published.
  • All acceptance tests have passed.
  • Code has been deployed to QA/Test server.
  • Tester has ran automated tests with no issues.
• If the company has specific standards that need to be followed such as coding, security and architectural standards then the team may initially build consensus around them and inspect them during design and code review sessions or add them to their definition of Done.

Business Case Development:

• I think what is needed to understand here is how an Agile business case may differ from traditional business case development. An Agile Business Case could still be born during the traditional ‘Initiation’ phase which may also be referred to as ‘Visioning’ or ‘Feasibility’ in Agile and needs to have  ‘Just Enough’ or ‘Barely Sufficient’ analysis as Alistair Cockburn would say.
• An Agile business case may use techniques such as ‘Design the Box’ for defining the vision and objectives and should also include very clear conditions of satisfaction and measures for success (also called Project Level Definition of Done).
• High level requirements, a high level roadmap along with high level estimates could be submitted with the knowledge that after execution of a few iterations these estimates will be continuously updated to reflect the team’s new knowledge and actual velocity.

Applying New Agile Practices:

• Understanding how to effectively introduce Agile practices to a team through:
• Initial education on the Agile values, principles and drivers behind the need for this change in mindset.
• Gaining the teams buy-in for piloting the new practices by understanding how they address existing pain points or solve business problems.
• Using Adaptive Leadership to continuously inspect and adapt the practices after piloting them and defining a strategy for rolling them out to the larger organization.
• Defining Project and Team Charters to capture the team values and norms.

Organization and Regulatory Compliance:

• Understanding how an Agile team could address with organizational compliance related issues by using a higher body such as an Agile PMO to negotiate reasonable processes that satisfy both the needs of the team and the business instead of being the enforcer who dictates these processes with no input from the team.
• Teams need to work with their auditors to find the ‘right’ level of documentation that is actually needed to pass regulatory compliance and not just assume existing documents and processes that have been established for years cannot be improved to be more effective and efficient.

Innovation Games:

• You should know what innovation games are about (created by Luke Hohmann), why we use them and know the top ones such as Product Box (used during visioning) and Buy a Feature (used for prioritizing).

Control Limits:

• My thought is that this could be referring to the comparison between traditional Six Sigma ‘Defined Process Control’ where control limits are defined for product quality and defects (for example the production must yield less than 3.4 errors in one million) and Agile/Scrum which uses ‘Empirical Process Control’. Ken Shwaber argues that software is too complex to expect defects to be defined within specific error limits. However, Deming’s Plan-DO-Check-ACT (PDCA) cycle is well received in Agile as a form of inspect and adapt cycle.

Earned Value Management (EVM):

• I would read this great article by my colleague Mike Griffiths: Agile Earned Value Management (EVM)
• This is also another short and great read on Agile EVM by Tamara Sulaiman

Prepare for YOUR PMI Agile Certified Practitioner (PMI-ACP) ^SM Certification Exam:

• Upcoming PMI-ACP ^SM Certification Exam Prep On-site and Virtual Workshops (21 PDUs) – Learn from top Agile Practitioners and Experts!
• Join the PMI-ACP Study Group on LinkedIn (dedicated to discussing this exam, feel free to post your questions or feedback after taking the exam)
• Join the PMI Agile Community of Practice (lots of great Agile information and webinars by experts and community members)
• Join the PMI Learning and Education Community of Practice (I’m the Agile Expert for this community and host a ‘Transforming to Agile’ series of monthly webinars and blogs that are pretty popular, hope you can attend the next one on Agile Idea Qualification and Project Initiation)

Sally Elatta – President Enterprise Coach & Trainer http://agiletraining.com/

About Me: I am simply a transformer. Someone who is really passionate about helping organizations move towards building lean high performing collaborative teams that can deliver value predictably. I like to find practical solutions to solve real problems and use a combination of Agile, Scrum, Lean, Soft Skills and Servant Leadership to reach the desired target. I am the Agile Expert for the PMI Learning, Education and Development (LEAD) community of practice and I host a popular Agile webinar series and blogs on transforming to Agile. New PMI Agile Certified Practitioner (PMI-ACP) SM Certification Exam Prep Workshops! Full profile/bio: http://www.linkedin.com/in/elatta

My PMI-ACP ^SM Certification Exam Retrospective

What Worked Well

First, my overall feedback is that the exam was pretty good, especially being this is the pilot and there will be updates and improvements based on our Agile value of inspecting and adapting .  I would say 80% of the questions were pretty clear especially if you have Agile experience. If you are new to Agile you may choose a few incorrect answers that do seem pretty reasonable but are tricky because they describe how it was done traditionally. So here is what I liked about the exam:

• I thought the coverage of all the various Agile methods (Scrum, XP, Lean and Kanban) was well spread out.  There are many more questions on Scrum and XP than I had initially anticipated but I thought they were good to have.
• I liked the fact that the exam had several questions on team dynamics, empowerment and collaboration. Questions around creating high performance teams, osmotic communication, moving out of command and control to Servant Leadership and team empowerment were all great to see.
• There were several questions on the four Agile Values, in addition to comparisons of the Agile Values and Principles with the Lean Principles which was great because it emphasized how strong these two are joined.
• I particularly enjoyed (and had several smiles and giggles during the test) some of the tricky options that seemed very logical but would not align with the spirit of Agile.
• I liked the fact that Lean Portfolio Management was included but not to an advanced degree. You basically needed to know what Lean Portfolio Management was, understand its value to the business and understand what a Value Stream Map provides for you.

What Needs Improvement

• There were some inconsistencies that (I believe) were a result of the different terminology used between the recommended reference books. For example, you will see ScrumMaster, Agile Project Manager, Agile Leader and the XP Coach all being used. I’m ok with ScrumMaster used in the context of Scrum and Coach used in the context of XP questions, but I think Agile Project Manager and Agile Leader will be confusing so picking a common ‘generic’ Agile term might be useful.
• Some questions were confusing because they were not well worded and taken out of a specific chapter in a book. For example, a question around ‘Agile Project  Values are best implemented when specified by the …’.  My first reaction to the word ‘Project Values’ was project ROI which would point to the Product Owner, but then I thought maybe they mean the Team Values and norms? Oh, wait maybe Project Values are the project estimates?? Upon the review of the recommended books, it was clear this was related to Agile Team Values and norms.
• I was puzzled by the reference to some techniques such as Monte Carlo Analysis, the Parato Rule, ‘the Risk Audit Meeting’ only because there were several questions on them and for some reason I didn’t see them (or perhaps missed them) in the exam guide. They are also not standard terms we use all the time so it caught me by surprise even though I managed to get the right answer by process of elimination. If we are going to keep them (or perhaps reduce the number of questions on them) then we just need to refer to them in the exam guide.

Overall, this was a good exam, especially for being a pilot. I’m very happy to share that Rory McCorkle, the product owner for this exam, has empowered the Agile Community of Practice to continue to provide feedback to improve the questions and content covered. The steering committee will be meeting this December to do a final retrospective in the spirit of inspecting and adapting .  Also, in case any of you are wondering if I’ve crossed the line with my sharing above, I did pair with Rory to review this blog to make sure everything was safe to share!

Prepare for YOUR exam:

Sally Elatta – President Enterprise Coach & Trainer http://agiletraining.com/

About Me: I am simply a transformer. Someone who is really passionate about helping organizations move towards building highly engaged collaborative teams that can deliver value predictably. I like to find practical solutions to solve real problems and use a combination of Agile, Scrum, Lean, Soft Skills and Servant Leadership to reach the desired target. I am the Agile Expert for the PMI Learning, Education and Development (LEAD) community of practice and I host a popular webinar series and blogs on transforming to Agile. New PMI Agile Certified Practitioner (PMI-ACP) SM Certification Exam Prep Workshop! Full profile/bio: http://www.linkedin.com/in/elatta

The Four Levels of Agile Requirements

Don’t you just love the word ‘Requirements’? It’s just so clear isn’t it – NOT! Have you ever heard your business customer say ‘I’ve already given you my requirements’ and the team then says ‘We haven’t received clear or detailed  requirements’? the other side to this is when the team tells the customer ‘You are giving us too much details, don’t tell us where the button goes on the screen, just tell us what you want’.  No wonder we have so many requirements related issues on our projects!

During one of my previous PMI webinars we talked about  Agile Requirements – Breaking Down EPICs and Prioritizing.  I’ll take a stab through this blog at summarizing the levels of Agile (and frankly non Agile) requirements and how you can use a four step process for gathering them.

First, let’s start with the picture below. The picture shows 4 levels of requirements and also on the left is the 4 step process for gathering requirements.

Visioning

: This is the initial step of gathering requirements. The goal is to help identify all the Themes and some features desired. This exercise begins to define the scope of what is expected.

Brainstorming

: The goal of this step is to identify all the features and stories desired. The key here is Breadth First, Depth Later. So instead of discussing the details of each feature and story, our main goal is to FIND all the features and stories.

Breakdown

: The goal of this step to breakdown and slice the stories that are still too large (EPICs) into smaller chunks. You probably have already done a lot of slicing during brainstorming but as you comb your backlog, the team will realize that some stories are still too large to be completed within an iteration (usually 1-4 weeks). Slicing stories is an art and I will dedicate an entire blog to it!

Deep Dive

: This is the step everyone wants to jump into right away! Yes, finally let’s talk about the details. What will be on the screen, what are the exact business rules and how will we test them, what will the detailed process look like, what are the tasks we need to get done to complete this story. Jumping into this level of detail upfront during the initial phases is one of the main reasons contributing to scope creep later during the project.

Suppose we are developing a system for an online job posting site OnStopJobs.com. Here is an example of what the requirements could look like based on the levels above:

1.     Employer Area – Theme

a.     Manage Jobs – Feature

1.As an employer I want to post a job so others can find it. Story

2.As an employer I want to modify a job posting so it is correct. Story

3.As an employer I want view a list of my open job postings so I can analyze them.  Story

4.As an employer I want to expire a job posting so no one can apply. Story

b.     Manage Applicants

1.As an employer I want to view the list of recent applicants so I can respond to them.

2.As an employer I want to view the list of applicants for a specific job positing so I can qualify them.

3.As an employer I want to select the top candidates so I can interview them.

You should gather the levels above (Themes, Features, Stories) upfront when you are planning out your release, especially if you have the raditional projects with begin and end dates. We usually spend more effort on the stories that are coming up in the next few iterations or the next release.

The Deep Dive is where the main difference lies between Agile and Waterfall. Traditional teams would gather this very detailed information upfront for ALL the stories on the backlog, where Agile teams will gather these details Just In Time for the next stories, which is one or two iterations before that story needs to be DONE.

Here is an example of what the details could look like for this selected story:
“As an employer I want to post a job so others can find it.”.

Acceptance Criteria/Tests
(How will we know when we’re done):

1.     UAT1 – Verify that only an authorized user with a valid employer account can post a job.

2.     UAT2 – Verify that a duplicate job posting cannot be entered.

3.     UAT3 – Verify that the posting date is past today’s date.

4.     UAT4 –Verify that the positing expiration date within 90 days.

5.     UAT5 – Verify that the screen fields pass our standard field format rules.

6.     UAT6 – Verify that all required fields are entered.

Acceptance criteria are the ‘details’ of the story and they are considered primary requirements in Agile. We gather them upfront before any development begins.

Sample Tasks (The work we need to do to get this done):

1. Create a database tables to store the job posting details.

2. Design and build the screen for job posting.

3. Develop the logic for UAT1 to pass.

4. Document/record the on page video help for the job posting page.

5. Perform user acceptance testing.

6. Deploy the code to the test environment.

7. ….. others..

UI Prototype/Wireframe and Activity Diagrams:
These could be hand drawn sketches of the screen or the process steps involved for the system to accomplish the process defined.

Quiz Time – What is What?

Would you like to test your skills and ability to differentiate between the various levels of requirements? Take a look at the list of requirements’ below and jot down your thoughts on if each item is a Theme, Feature, Story or the Details of a story. I’ve purposely made them tricky and some of them could have two answers depending on the context you define. I will share the answers in my next blog so stay tuned!

a)     We need the ability to filter our reports by date and group #.

b)     We want to manage user access to the site and limit who has access to what.

c)     We want to make sure that only Managers can access the salary data.

d)     We want customers to pay using credit cards online.

e)     We want to verify that discover card payments are not allowed.

f)      We want scheduled and ad hoc reporting.

Please post a comment or question below and share with us your own experience and challenges with requirements. Do the levels above make sense? Do you see value in organizing requirements this way? Please share any tips you have with managing the levels of requirements.

Sally Elatta – President Enterprise Coach & Trainer http://agiletraining.com/

About Me: I am simply a transformer. Someone who is really passionate about helping organizations move towards building highly engaged collaborative teams that can deliver value predictably. I like to find practical solutions to solve real problems and use a combination of Agile, Scrum, Lean, Soft Skills and Servant Leadership to reach the desired target. I have an interesting mix of technical background as a software Architect in addition to business skills that help me connect with audiences at various levels. My goal is to transform individuals, teams and organizations to doing what they do better.  New PMI Agile Certified Practitioner (PMI-ACP) SM Certification Exam Prep Workshop! Full profile/bio: http://www.linkedin.com/in/elatta Project Manager Agile LearningRoadmap

A Journey Through the Agile Lifecycle

My last PMI webinar was on the ‘Journey Through an Agile/Scrum Project Lifecycle’ and I wanted to summarize some of the key points discussed. If you haven’t attended then feel free to watch the recorded version (requires PMI membership).

To understand the Agile Lifecycle, we’ll analyze the diagram below and walk through the key activities of each step.

1. Not all projects are the same. If your project is a small project that focuses on continuously delivering on smaller enhancements and support requests then you may not need much or any of Release Planning and Iteration 0. However, many of the projects we’ve been on have needed ‘just enough’ of these two important steps. Skipping these entirely usually results in many impediments throughout the rest of the iterations.
2. Many Agile/Scrum teams would prefer a ‘Product Development’ type of approach in contrast with a ‘Project’ approach that has a begin and end date and where teams are built then disbanded after each project. Of course, after understanding Agile you will see why keeping teams stable and having continuous flow of value would be to your advantage. I believe you could use the lifecycle above for either types of approaches with minor adjustments based on project type.
3. The steps above do not include the Project Initiation/Visioning phase which happens before Release Planning. We will cover this in later webinars and blogs.
4. Some teams don’t see a need for Iteration 0. They feel that once you have done a bit of planning then you can begin to iterate and the initial iterations/sprints will need to cover the foundation type work anyway (hence having an Iteration 0 but not really calling it out as such). So don’t get caught up in terminology, the important thing is that you’ve planned for critical foundation items needed ahead of time.

During our next webinar we will cover Agile Requirements – Breaking Down EPICs and Prioritizing. Hope you can join us! If not, look for the recorded version online.

Please post a comment or question below and share with us your own experience with the Agile lifecycle, do the steps above make sense? Have you experienced them on your projects? What tips do you have for the community members?

PMI Agile Certified Practitioner (PMI-ACP) ^SM Certification Live Webinar Interview

As I mentioned in my recent post, I will be hosting Rory McCorkle, the Product Owner for the new PMI Agile Certified Practitioner (PMI-ACP)^SM Certification, on a live webinar on March 17^th at 12pm EST on the Learning and Education CoP. We will also have a live twitter chat going under the #pmiagilecert tag so be sure to follow the conversation or tweet your questions. This is our first time doing a live webinar/twitter chat combination so we hope it will serve the purpose of engaging both the PMI and Agile community members.

Please post here any additional questions you are interested in asking Rory about this certification. My previous post has the ones he answered for us but I’m collecting questions for the upcoming webinar.

-Sally

« Previous Page — Next Page »