AgilePM Project Management - Foundation and Practitioner

About the Lesson: This module provided a brief introduction to the basic components of Agile Project Management, the overarching philosophy and the eight principles that underpin the way Agile Project Management works.

 About the Lesson: This lesson gave a brief overview of each of the main components and their contribution to the Agile Project Management approach.

About the Lesson: This lesson compared the difference between a Traditional approach and an Agile approach to project management.  In a traditional approach Time, Cost and some elements of Quality are often negotiable to deliver a fixed set of features.  Using an Agile approach Time, Cost and Quality are fixed and the Features are negotiable to enable the Project to deliver on time and within budget.

About the Lesson: This lesson emphasises that the successful implementation of Agile Project Management is dependent on the stakeholders understanding of the underlying Philosophy of the approach.

About the Lesson: This lesson introduced the eight Principles that underpin the Philosophy. Application of the Principles ensures organisations receive maximum benefit from using Agile Project Management.

About the Lesson: This lesson investigated the Principle of Focus on the Business Need.

One of the major strengths of Agile Project Management is the high level of direct involvement from the business on projects. It is important that this is maintained throughout the project.

 About the Lesson: This lesson introduced the principle of Deliver on Time. Using Agile Project Management assures the stakeholders that the Project will be delivered on time.

About the Lesson: This lesson investigated the principle of Collaborate. The strong emphasis on collaboration between all parties in Agile Project Management enables teams to perform at a level that exceed the sum of their parts.

About the Lesson: This lesson introduced the principle of Never Compromise on Quality. The quality to be delivered should be defined at the outset and a solution has to be “Good Enough” - no more, no less.

About the Lesson: This lesson investigated the principle of Build Incrementally from Firm Foundations. This principle underpins the Lifecycle, establishing a sound understanding within Feasibility and Foundations before developing incrementally during later phases.

About the Lesson: This lesson introduced the principle of Develop Iteratively. The concept of iteration is embedded throughout the lifecycle right down to Timeboxing.

About the Lesson: This lesson investigated the principle of Communicate Continuously and Clearly. Agile Project Management is designed to improve effective communication for all parties involved in the project.

About the Lesson: This lesson introduced the principle of Demonstrate Control. Control is not just viewed as a project management issue – this principle applies to the whole team. The use of Foundation Phase products and well defined Timeboxes all contribute to demonstrating control.

About the Lesson: This module has outlined the basic components of Agile Project Management to provide you with a framework to help with your understanding of the approach. Each of the Principles has been looked at and how they support the Agile Project Management Philosophy.

Consider whether you have met the learning objectives.

Attempt the Match the Principle Task (which can be found under resources – Task2a)

Read the Case study and then attempt the Module task

Review the Principles Top Tips

Attempt the module Foundation Test and review and act upon the feedback.

About the Lesson: This module identifies each of the Agile Project Management roles and explains the three main role categories of Project, Solution Development and Other.  It also identifies key responsibilities for each of the individual roles.

This lesson introduces you to the “Alien Baby”, each role and responsibility is explained in more detail in the following lessons.

This lesson has introduced the Business Sponsor, the highest point of escalation in the project. Their responsibilities include: Empowering the business roles within the project, to appropriate levels, within their responsibilities; and to Keep themselves informed of progress and issues, e.g. by attending demonstrations at the end of Timeboxes and asking questions of other roles who are more actively involved.

On a small project the Business Sponsor role will always be taken by a single person but on a larger project or complex organisation the financial responsibilities may be fulfilled by an investment board or executive committee. However, DSDM still expects the business to agree a specific person to “front” the role ensuring that there is one decision maker and a single escalation point. If there has to be more than one Business Sponsor then the Project Manager should know the agreed escalation procedure and have direct contact with an empowered individual at this level

About the Lesson: This lesson has introduced the Business Visionary who provides strategic direction, defining, communicating and promoting the business vision.

About the Lesson: This lesson has introduced the Project Manage who co-ordinates all aspects of management of the project at a high level. It is important to remember that the Agile Project Manager is more facilitative rather than command and control. Their responsibilities include: Handling problems escalated from the Solution Development Team and providing help and guidance where difficult situations arise; and Attending Daily Stand-Up meetings, as appropriate to keep a current understanding of the Team's progress and issues, and to flag up to the Team, where necessary, any important external issues that they need to be aware of.                                                                                       

About the Lesson: This lesson has introduced the Technical Co-ordinator who is the project’s technical design authority.  Their responsibilities include: Empowering the technical roles within the Solution Development Team to appropriate levels within their responsibilities; and  Acting as the final arbiter of technical differences between Team members.

The Technical Coordinator needs to ensure appropriate technical reviews are carried out and testing is comprehensive and rigorous enough to provide confidence that the solution is fit for purpose.                  

About the Lesson: This lesson has introduced the Team Leader and Business Analyst role. They are both part of the Solution Development Team.

The Team leader is appointed by their peers as the best person to guide them through a particular area of the solutions development.

The Business Analyst also has a large part to play in Feasibility and Foundations. They are responsible for, or a major contributor to the products with a business focus for example the Business Case, Feasibility Assessment and the Prioritised Requirements List.  They also ensure the business and technical components of the solution collectively provide a cohesive whole for the business.

About the Lesson: This lesson has introduced the Solution Developer, Solution Tester and Technical Advisor. They are all part of the Solution Development Team.

The Solution tester is responsible for carrying out all types of testing except for:

•           Business acceptance testing is the responsibility of the Business Ambassador and the Business Advisors.

•           Unit testing which is the responsibility of the Solution Developer     

About the Lesson: This lesson has introduced the Business Ambassador and Business Advisor roles that are both part of the Solution Development Team. The Business Ambassador works very closely with the Solution Development Team to guide the evolving solution. The Business Advisor role is often called upon for their particular specialist input into the solution development and testing.

Business acceptance testing is the responsibility of the Business Ambassador and the Business Advisors.

About the Lesson: This lesson has introduced the Workshop Facilitator and DSDM Coach. An independent, trained Workshop Facilitator ensures that the full benefit can be obtained from Facilitated Workshops. A DSDM Coach can be a great asset to a team adopting Agile Project Management to ensure they get the most out of the approach.

About the Lesson: This module has explained the Agile Project Management roles and responsibilities. They may differ from traditional project management roles but they ensure that there is a high level of collaboration across all stakeholders.

The project organisation can be easily refined to support multiple teams, with key roles acting as coordinators across the teams.                                                              

The decision to use Agile Project Management needs to be weighed up against the possible risks involved. This module will look at  these risks and the fundamental aspects of Agile Project Management that make it different from a more traditional approach.

The Project Manager is responsible for motivating the team and for keeping up morale. Experience also shows that, over time, the Solution Development Teams become more self-motivated as they are given more responsibility for making decisions. 

This lesson has looked at how Agile Project Management requires a different style of management that a
more traditional style of project management. Progress is monitored by products
produced and the Team need to be motivated and empowered to make decisions.

This lesson compared the management style often seen on traditional projects, that is a more 'tightly
managed team' to the Agile approach which is encouraging 'Self Directed Teams'

This lesson looked at the risk factors that any organisation need to consider when adopting an Agile
approach. The organisation needs to think about how the Principles can be applied, whether the people are committed to the approach and how much is understood about the variables. 

This lesson looks in more detail about the approach Agile Project Management takes to fixing the constraints of Time, Cost and Quality and varying the features.

When problems arise the Solution Development team need to be able to deal with them quickly. They have more flexibility to make decisions for themselves than more tradition style teams. But, there is a limit to this flexibility, anything that may affect the breadth of what they are developing needs to be escalated to the appropriate level on the project.

This lesson has introduced the factors that are seen as Instrumental to the success of any Agile project.

The five main Instrumental success factors are:

1.         Embracing the DSDM Approach – this means embracing the DSDM philosophy that “best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people”. This also includes the understanding that in order to manage change dynamically the project might not deliver 100% of the initial requirements.

2.         Effective Solution Development team – this focuses on four elements; Empowerment, Stability, Skills and Size

3.         Business Engagement – which needs to be active and ongoing

4.         Iterative Development, Integrated Testing and Incremental delivery – each timebox should deliver a complete, fully deployable element of the solution. Testing should be fully integrated into the development of the solution. Incremental delivery will allow organisations to benefit from early return on investment.

5.         Transparency -  is about making progress and ongoing work visible to all. Team boards and Daily Standups are very useful for communicating progress. 

Having a common understanding of what needs to be in place is a good starting point for any project, agreeing the optimum starting position for an Agile project increases the likelihood of a successful project. Where the instrumental success factors can’t be met they present risks to the Agile Project Management Approach.

Some of the risks may not be easy to resolve without tailoring the use of DSDM. Chapter 24 describes some typical ways that DSDM consultants have tailored Agile PM to the circumstances they have found in various  organisations and projects. 

Testing is important for any project but the Agile Project Management approach is to define the tests, wherever possible, before the development starts and test as early as possible, this is backed up by the saying “Test Early, Fail Fast”. Then there is time to correct the failures rather than leaving testing to the very end of development.

The DSDM key techniques are applied in testing, we have already mentioned MoSCoW in the lesson but Iterative Development allows for early testing and the chance to further test through each iteration. Timeboxing allows for risk based testing to focus on the most important tests first and repeatable, automated tests through the Timebox or Timeboxes to quicken up the testing activities. Using Facilitated Workshops allows for early walkthroughs of processes, documentation and modelling which support Fail Fast. Facilitated Workshops can also help to resolve defects and to assess the risk against a requirement and prioritise appropriate tests.

There a three broad classes of test:

Positive test – checking the product does what it should

Negative tests – checking the product doesn’t do what it shouldn’t do

Unhappy path tests – checks the product when unusual events occur.

Each test should have a defined starting state, a defined set of actions which will be carried out and the expected outcome.

The Technical Coordinator should ensure that appropriate reviews are carried out and testing is sufficient to prove the product is fit for purpose.

The Solution Tester is responsible for all types of testing except:

Business acceptance testing which is the responsibility of the Business Ambassador and Business Advisors and Unit testing which is the responsibility of the Solution Developer. 

Configuration management is an important control for any type of project but care needs to be taken not to
allow it to slow down the progress of the project. The formality needs to be appropriate to the needs of the project but should not be so formal that it prevents change.

This module has introduced the Instrumental Success Factors which are important to the successful application of Agile Project Management. It also looked at the Project Approach Questionnaire which is key in determining some of the risks of using Agile Project Management.  The Testing concepts that help to enhance the delivery of the solution and appropriate use of Configuration Management were also investigated.

This module will look at the first three phases of the Agile Project Management Lifecycle. These are Pre-Project, Feasibility and Foundations. They are concerned with ensuring that there is sufficient understanding of the end solution to prove business viability and justify development work to start. This module will also look at the Agile Project Management Products that are produced during these phases.

This lesson has presented a brief overview of the Agile Project Management Lifecycle. The project Lifecycle has six phases. Pre-Project, Feasibility and Foundations are produced broadly sequentially. They lead on to Evolutionary Development, which can be configured in many ways to account for the varying iterative and incremental development methods used for different types of projects. There might be one single deployment or many deployments and after the solution has been in operational use there will be a Post-Project phase to measure the business value achieved.

This lesson looked at the overview diagram that shows each of the products that can be created and developed over the lifecycle. They are colour coded to show which of the three main perspectives, business, solution and management, they represent.

To support a more complex project structure, products such as the
Solution Architecture Definition, Development Approach Definition, Management
Approach Definition, the Delivery Plan and Timebox Review Records can be made
more elaborate and more formal than they would need to be for smaller projects 

This lesson looked at the objectives of the Pre-Project phase and the Feasibility Assessment product created during this phase.

This lesson investigated the Feasibility Phase, deigned to do just enough to justify whether the project is viable from a business and solution perspective.

This lesson looked at the Feasibility Assessment and Outline Plan which are produced during the Feasibility phase.

During the Feasibility phase the Project Manager works with the other project roles and particularly the Business analyst to establish whether the project is feasible. The evolutionary products created here help to establish the work to be done and which of the six foundation products need to be created in outline. The Feasibility Assessment collates these findings and is a milestone product presented to the Business Sponsor for assessment of whether the solution is likely to meet the business need. Not all business propositions will make it to the Foundations phase. 

This lesson looked at the
aim of the Foundations phase is which is to establish a firm base for the
project from the business, the management and the solution perspective.

This lesson looked at the Foundation products which ensure firm foundations are in place before moving into iterative development. A brief overview of each of the products is given here. Each product is explained in more detail in section 8 of the Agile Project Management Handbook. It is worth taking some time to study this section.

The evolutionary products were created in outline in Feasibility and the Foundations phase makes them robust enough to establish firm foundations before moving into iterative development.

The Delivery Plan includes the dates of each increment, the dates for deployment of the solution or subsets of the solution and any other key milestones that need to be captured.

This module has introduced the Agile Project Management Lifecycle and Products. It then focussed on the first three phases of the lifecycle and the products created during the Pre-Project, Feasibility and Foundations.

For those of you who are studying for Practitioner it is worth taking
some time to look at Chapter 16 which covers the effective use of the DSDM
products.

This module will look at the evolutionary development phase, the Deployment phase and then the Post Project phase of the lifecycle. The Products created or updated through these phases will be introduced and which role is primarily responsible for them.

This lesson has looked at
the Evolutionary Development phase and broadly what is done within it. The main
objective is to build the right solution, from a business perspective and to
incorporate the non-functional requirements, often called the “ilities” such as
reliability, supportability, maintainability.

This lesson has looked at 

the Evolutionary Development phase from the perspective of the Project Manager describing their responsibilities during this phase.

This lesson has looked at
the Products produced in the Evolutionary Development phase and the roles responsible for their creation.

This lesson has looked at how the DSDM process can be configured and different project lifecycles that can be created.

DSDM can be scaled to support multiple teams, with key roles acting to coordinate across the teams. A more complex project structure may require the Definition products , Delivery Plan and Timebox Review Records to be more elaborate and formal than would be needed for smaller projects.

This lesson has covered the
Deployment phase, the Project Managers responsibilities and the Project Review Report created in Deployment.

This lesson has looked at
the Post-Project phase and Benefits Assessment product that is produced in this phase. There may be more than on Post-Project assessment depending on the useful life span of the solution. The aim is to look at what benefits are actually being realized as the solution is being used.

This module has looked at
the Evolutionary Development Phases. It then looked at the Deployment phase for delivering the solution, or a working component of the solution, into live use. Finally the Post-Project Phase was discussed to assess whether the benefits promised by the project were actually being achieved.  The Products created or updated through these phases were introduced and which role is primarily responsible for them. 

This module looks at how communication in an Agile project is greatly enhanced by using the five Agile techniques of Facilitated Workshops, Modeling, Iterative Development, MoSCoW prioritization and Timeboxing. The Daily Stand-up and its contribution to effective communication is also looked at.

This lesson looked at how Communication is enhanced by using the Agile Project Management approach.

A key responsibility throughout the project is for the Project Manager to build and support a “one team culture”. For that reason the project manager should be focussed on working with the team to put in place techniques and practices to support effective communication. However that does mean communication is the sole responsibility of the Project Manager because good communication requires thought, planning and commitment from the whole team.

This lesson introduced how using Facilitation Workshops and the use of an independent, impartial Facilitator can enhance communication.

Crucial to the success of the workshop are having well defined objectives and being well prepared.

This lesson looked at how the production of Models, which can be diagrams, rough sketches through to working prototypes, can enhance communication. 

This lesson has looked at how the Daily Stand-up contributes to on-going, informal and where possible, face-to-face communication which relies on team members being open and honest.

This lesson has looked at how the Solution Development Team use Iterative Development to evolve the solution from a high level concept to a deployed solution incrementally or as a whole.

This lesson has focused on explaining the MoSCoW technique and how much effort is concentrated on the Musts, Shoulds and Coulds.

The MoSCow technique depends on the priorities set for the requirements. This lesson looks at the prioritisation of requirements in a little more depth to investigate what happens when there is a high level of Must Have requirements set.

This lesson looked at Timeboxing in more detail. A Structured Timebox contains three main stages; Investigation, Refinement and Consolidation which are preceded by a short Kick-off session and concluded with a short Close-Out session. A free-format Timebox can also be used when using other development methods such as SCRUM or when little formality as needed.

It also looked at the Timebox plan, who it is created by and what it contains. 

The focus of this lesson was on the way that Iterative development is used within each of the three Timebox stages to 'identify', 'plan', 'review' and 'do'. The lesson also looked at the review sessions which are supported by the Timebox review records. 

This lesson has looked at how good communication are major factors in ensuring successful projects and uphold the two principles of Collaborate and Communicate continuously and Clearly.

This module looked at how using the five Agile techniques of Facilitated Workshops, Modeling, Iterative Development, MoSCoW prioritization and Timeboxing promote effective communication between the team and the wider stakeholders. The Daily Stand-up and its contribution to effective communication within the Solution Development Team was also looked at. 

The objective of the module is to look at the Control parameters that are used in Agile Project Management. It also looks at Risk, Requirements, Estimation and Measurement in more detail.

This lesson has looked at how the use of Timeboxes during the development work of the project is a major control mechanism for ensuring that the Must have and most of the Should have requirements are delivered. The style of Project Management is different from that of a traditional project and control is focused at a lower level. 

This lesson revisited the project Variables. Time, Cost, Quality and Features. When problems occur during the project the Features variable is the only one that can be changed. It is vital that organisations using Agile Project Management fully appreciate this from the outset of the project if the approach is to be successful. Tolerance around the feature is built into a Timebox by using MoSCoW prioritisation but if the Solution Development Team believes that they will not meet all of the Must have requirements or delivering the Must and Should have requirement will compromise quality then this is considered to be an exception. This should then be escalated to the project level roles. 

Because the field of risk management is well established extensive guidance is readily available and it is not repeated in the AgilePM.  You might find it interesting to look at the guidance given in the Project Risk Analysis and Management Guide, APM publishing 2nd Edition 2004 or Management of Risk: guidance for practitioners 2010 Edition from Axelos. The PRAM guide defines risk as “The exposure of stakeholders to the consequences of variations in outcome”

The main risks that are considered in DSDM are those relating to the approach taken. As you have heard in this lesson monitoring the ISF’s the use of the PAQ and adherence to the Principles can greatly reduce these risks. These key risk areas include:

• Levels of business involvement and commitment
• Team skills. Ability and availability
• Clarity of vision without defining detail too early
• Maintaining focus on delivering on time by varying features

During Feasibility and Foundations there is large focus on identifying risks and identifying what to do about them but it is also critical that risks are managed throughout the project. New risks arise and those already identified may change. Once in Evolutionary Development risks are revisited at the beginning of each Timebox as part of the Kick-Off where further risks are often identified when investigating more detail of the requirements and previously identified risk reassessed.

The Project Manager is accountable for the effectiveness of risk management but each risk should have owners identified. The Business Visionary and Business Sponsor are kept informed about risks and will often take ownership of key risks they are best placed to manage.

This lesson has looked at what a requirement is and how the nature of the requirements change over the project lifecycle from high level at the outset to more detailed as more is known and development work is started.

This lesson has looked at the contribution the Business Analyst makes to the definition and delivery of  the Requirements during Feasibility, Foundations and Exploration and Engineering. The Business Analyst is fully integrated role within the Solution Development Team. They focus on the relationship between the business and technical roles and ensure that accurate and decisive direction is provided on a daily basis.

This lesson has looked at the contribution the Business Analyst makes to the definition and delivery of the Requirements during Feasibility, Foundations and Exploration and Engineering. The Business Analyst is fully integrated role within the Solution Development Team. They focus on the relationship between the business and technical roles and ensure that accurate and decisive direction is provided on a daily basis.

This lesson has focussed on what estimating is used for and the difference between estimation in an Agile Project and a more traditional project.

Accuracy of estimating can be improved by using more than one technique and by using multiple people, especially by involving those who will be doing the work. There are two broad styles of estimating, Top Down and Bottom Up.

Two common techniques for Top Down estimating are:

T Shirt Estimating – applying Small, Medium, Large and Extra Large to a requirement – used when little is known about the item being estimated.  Estimating by Example is used to break a requirement down, using bottom up estimating for a small number of stories to help determine how long each of the S, M. L and XL requirements are likely to take.

Story point Estimating – consensus based which uses discussion to assign a relative size to a story – more time consuming than T Shirt estimating but more accurate. Estimating by velocity is related to Story Point Estimating – based on a team’s previous performance in terms of how many story points they can deliver in a Timebox. This is then used to predict what can be expected in the future.  See Appendix C for Estimating Using Planning Poker and Velocity.

Bottom Up Estimating is the most time consuming and is used during Timebox planning. It would be far too time consuming to use Bottom up estimating in Feasibility and Foundations. Each requirement is broken down into individual elements, each element estimated and hen the total effort for all elements calculated. This may break down into a series of sub-products, a Product Breakdown or a series of tasks and create a Work Breakdown.

Take a look at Chapter 20.3 for more on different styles of estimating. 

'This Module focused on the way in which Agile Project Management ensures that there is an appropriate amount of control over the project. 

The objective of this module is to look at the style of planning used in Agile Project Management and how the level of Quality required by the project influences planning. It also looks at each of the planning products, the Delivery Plan, the Deployment Plan and Timebox plans in more detail. 

This lesson looked at what planning means in an Agile project. It dispels the myth that Agile projects don’t need planning. An overview is produced during Feasibility and Foundations and then each Timebox is planned in more detail, where there is closer proximity to the work and estimates become more accurate.

This lesson looked at the definition of ‘Solution Quality’, which ensures that the end solution or partial solution is fit for purpose and ‘Process Quality’, which ensures that there is a predictable and repeatable process for delivering the solution.

This lesson looked at how the techniques used in Agile Project Management and the composition and responsibilities of the roles help to build quality solutions.

This lesson looked at how the level of maintainability required by the solution influences the planning considerations. Is maintainability a key influence on the development work, is it more important to get something out to the business they can use and re-engineer later or is it a tactical, short-term solution and acceptance will not consider maintainability?

This lesson looked at each of the planning products and the influence one product has on another, through the Agile Project Management Lifecycle.

This lesson looked at the purpose and content of the Delivery Plan produced during Feasibility.

This lesson looked at the purpose and content of the Delivery Plan produced during Foundations and the Timebox. 

Achieving  a sensible balance of effort during in the Delivery Plan is a collaboration of effort with:

•           the Business roles ensuring priorities meet the business need and the grouping of requirements for Increments meet business deadlines

•           the solution/technical roles working to ensure plans are realistic, achievable, reflect technical constraints to meet the business priorities

•           the Business Analyst considering the links between requirements and helping to  identify viable groups of requirements

•           the Project Manager ensuring the balance of priorities reflect the known level of risk on the project

The Timebox Plan the planning is owned and driven by the Solution Development  Team roles at the beginning of each Timebox where the Project Manager is an interested bystander ensuring that:

•           the balance of priorities is being applied sensibly

•           the team takes into account the level of risk in balancing the priorities

•           the team takes
ownership of their estimates  as a whole.

This lesson looked at the purpose and content of the Deployment Plan produced during Evolutionary Development.

There will often be a need to revisit Foundations at the end of each Project Increment in order to check that the project is still viable and that the next increment is still required. Plans for the next increment will need to be firmed up. The schedule of Timeboxes will need to be produced and a check of the Management Approach and the Development Approach to make any necessary changes.

This lesson looked at the purpose and content of the Timebox Plans produced in Evolutionary Development.

This module has focused on the nature of planning and the influence that the level of quality required in Agile Project Management has on planning. It looked at each of the four planning products, their purpose and composition. 

The objective of this Exam Preparation module is to guide you through the format and question styles of the Foundation and Practitioner exams.  Techniques on how to approach each exam will also be explained.

Foundation Examination

50 Questions with multiple choice answers.  This is a forty minute, 'closed-book' examination where you need to score 50% or more to pass.

You need to pass this examination prior to taking the Practitioner Exam.  You should be confident of passing this exam as Agile Passport is geared to teaching you the AgilePM Method and it is your knowledge of the method that is being measured.

When you are ready to take the Foundation/Practitioner Qualification, please contact your Learning Service Provider – SkillSolve Training (admin@skillsolve.co.uk +44 (0)1202 970910) to arrange your exams.

The Foundation exam consists of classic multiple-choice style questions.  These may be simple 'true/false' questions, or a choice from a possible four options. 

Despite the different styles of multiple-choice questions, it is important to know that there will only ever be one correct answer for each foundation exam question.

It is advisable to approach the Foundation Exam by going through the exam paper three times.

Your first run through the exam paper should be to answer the questions that you know the answer to instantly.  Do not worry if you feel that you are missing a number of questions.  You will find that when you return to these questions on your second run, many will appear easier.

Your second run should be to answer the questions that require more thought.  By now, any nerves that you were feeling should have reduced, and you should now be able to more confidently analyse the question and use your knowledge to identify the answer.  Think about the processes, the lifecycle of an Agile project and which role might be responsible when considering your answers, and make sure you read the full question and all possible answers. This approach can help you to identify in which process a particular activity is carried out for example.

Your final run through the exam paper will be to complete the questions that you have not answered.  These are likely to be the lengthy worded questions, or a negative question.  Use a ‘process of elimination’ approach to give yourself a better opportunity of marking the correct answer. For example, if the question asks which statement is FALSE, look to eliminate the answers which have TRUE statements in order to break the question down.

Practitioner Examination

This is a 2 1/2 hour Objective Test examination.  It is an open book exam, allowing you to bring only the official AgilePM manual into the exam room. The manual may have tabs for marking up the sections, but no other documents are allowed to be inserted. You may however hand write notes or draw information physically onto the pages of the manual, which you are likely to naturally do whilst learning the method.

The Practitioner exam tests the candidate’s ability to analyse and apply the AgilePM method to a given project management scenario.

The Practitioner exam uses objective test questions which require a candidate to choose a response to a question from a set of choices for which the correct answer is pre-determined.  Each exam paper has a maximum of 80 marks, and you need to achieve a score of 50% (40 marks) over the four questions to pass.

Here is an example of a Practitioner ‘Assertion/Reason’ style Multi Choice question. There are a number of different styles of examination questions used within the practitioner exam paper.

The question types are:

•           Classic Multiple Choice Questions – ‘choose one from a list’ of possible answers

•           Multiple Response – ‘choose the correct options from a list’. Candidates must remember to select, but limit the number of responses to that requested in each question. If more responses are given than required by the question, the answer will be void.

•           Matching – involves linking items in one list to items in a second list. There is only one correct response to each question, but options can usually be used more than once or not at all.

•           Sequencing – events to be positioned in a sequence.

•           Assertion/Reason – each item consists of two statements, an assertion and a reason that could be linked by the word ‘because’. First the candidate must determine whether the ‘assertion’ is true or false and then whether the ‘reason’ is true or false. If both are true, a third step is required and the candidate must determine whether the reason is a correct explanation for the assertion. 

There are two questions styles that benefit from a structured answering approach:

Assertion/Reason style questions should be tackled using a 4 step approach:

• Decide whether the ‘assertion’ statement is true or false first, then…
• Decide whether the ‘reason’ statement is true or false, then…
• If either or both statements are false, you can select your answer, (C, D, or E) however…
• If both statements are true, you will need to decide whether or not the reason is a correct explanation for the assertion (making the answer either A or B)

Matching Style Questions:

Matching style questions are best tackled by linking the items to the given options by drawing lines from your chosen item to your chosen response on the question paper. This will help you get a correct link before marking your answers on the answer sheet. A pencil and eraser will be supplied with your exam pack, so any incorrect links can be corrected before selecting your answer.

This brings us to the end of this Course.

Consider whether you have met the learning objectives.

Review the support materials.

Attempt the Foundation Practice Test

Review the Practitioner Sample papers along with the sample answers and the reasoning.

We hope this course has prepared you well on your road to certification.

Feedback is welcome and appreciated.

Please send your feedback on your customer experience (from the point of purchase to sitting the exam to receiving your certificate) to your Learning Service Provider (SkillSolve Training  admin@skillsolve.co.uk +44 (0)1202 970910)