AgilePM® Foundation Exam Simulator

Rationale: Adopting an Agile approach that promotes 'No design up front' (NDUF) can make many larger and more strongly governed organisations nervous when significant risks paper delivering a solution in a complex, regulated organization. The NDUF approach seems to reflect the Agile principle of favouring customer collaboration over contract negotiation, by allowing requirements to emerge during development rather than being defined upfront. However, this approach can sometimes be a risk when working in complex environments where there are intricate corporate architectures, existing systems, or numerous external suppliers and stakeholders. In such cases, adopting an Agile approach that incorporates design work upfront will provide a more stable foundation for the project, reduce uncertainty and risk, and ultimately increase the chances of success.

Rationale: People working together effectively are the foundation of any successful project. Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association. This collaboration encourages increased understanding, greater speed, and shared ownership, which enable teams to perform at a level that exceeds the sum of their parts. Therefore, any successful project requires the foundation of people working together effectively.

Rationale: Checking how well the expected business benefits have been met is the most appropriate way in which the Post-Project phase adds value to a project. The focus of DSDM is to deliver business value through the regular delivery of working increments of the product. The Post-Project phase marks the end of the project, but it should not necessarily be viewed as the end of the product's lifecycle, rather it is the start of the operational phase of the product. During this phase, it is essential that the post-project activities are carried out to check how well the expected business benefits have been met, as this allows the team to understand if the product is doing what it was intended to do and make further adjustments as necessary. This process ensures that the product retains its value to the business and continues to grow as planned.

Rationale: The Project Approach Questionnaire (PAQ) checklist is used to assess whether the success factors described are likely to be met or whether action needs to be taken to counter any risks arising from these risks being undermined. PAQ is used first during the Feasibility phase of a DSDM project to help shape the work of the Foundations phase. The role of the PAQ is to understand and assess the essential factors that can contribute to a project's success in its early phases. It works primarily as a checklist for evaluating potential risks to the project's success and driving active management of the project risks.

Rationale: An DSDM team needs to be proactive when monitoring and controlling progress. DSDM emphasizes proactive monitoring and evaluation to identify potential project risks early on, ensuring that project outcomes meet the business's goals and objectives. This is achieved through regular communication, reflection, and creating a culture that brings all stakeholders together to address issues in a timely manner. A reactive approach is less effective and can result in missed opportunities or increased project risks. Being pragmatic is important, but it is not the focus of DSDM when monitoring and controlling progress. Being adventurous is also not necessary, but the team should be open to experimenting and adapting to change to take advantage of the opportunities presented.

Rationale: DSDM emphasizes that the purpose of a project is to deliver a product that is fit for its purpose and that this product must meet the agreed-upon acceptance criteria. Therefore, the correct answer reflecting what stakeholders must be prepared to deliver is a fit-for-purpose solution.

Rationale: In AgilePM, quality is a key aspect of the project development process and should be focused on throughout the project lifecycle. Two key areas of focus include the process and solution. The process refers to how the development work is carried out, including considerations such as development approach, testing strategies, and team collaboration. The solution aspect focuses on ensuring that the solution delivered meets the agreed-upon standards of quality, including acceptance criteria and functional requirements. By maintaining diligence in these two areas throughout the project, the team can ensure the delivery of a high-quality solution that meets the needs of the business.

Rationale: Successful "implementation" of the DSDM "Collaborate" principle can result in team performance that exceeds the sum of its parts. When individuals work in a spirit of cooperation and commitment, they achieve increased understanding, better speed, and shared ownership over their work. This synergy is essential for achieving the high-speed delivery of projects in DSDM. Focusing on individual performance or only engaging members loosely would negatively impact efforts to establish a "good enough" solution within an acceptable time frame, compromising the project's success potential. In contrast, a collaborative culture provides teams with the resources and support necessary to succeed together and produce optimal results.

Rationale: The Solution Development Team comprises several roles which include: Team Leader, Business Ambassador, Solution Developer, Business Analyst, and Solution Tester.

Rationale: The DSDM principle that involves breaking the solution into manageable Increments is Iterative Development. By following this principle, the DSDM team can converge on an accurate business solution through the iterative delivery of the right solution. The team takes an iterative approach to building all products and builds customer feedback into each iteration. Breaking the solution into manageable Increments helps the team address urgent business needs early and progressively increases the breadth and/or depth of the solution with each delivery. Embracing the change that comes with the iterative approach leads to the production of a better solution.

Rationale: To develop and implement a risk management plan. The Project Manager is responsible for leading the development and implementation of a risk management plan that identifies potential risks and outlines how they will be managed throughout the project. This includes creating risk assessments and mitigation plans, monitoring and reporting on the status of risks, and ensuring that appropriate actions are taken to mitigate any associated negative impacts to the project. Effective risk management is critical to the success of the project, and the Project Manager plays a key role in ensuring that risks are managed proactively and effectively.

Rationale: The assertion regarding late delivery that aligns with DSDM is that "it can frequently undermine the purpose of a project." By definition, DSDM is time-boxed, meaning the solution delivery is scheduled within a fixed amount of time. Delaying delivery can compromise the chances of the business benefits being achieved, and hence the rationale for the project. A project that is delivering late is not a successful project, at least not in the eyes of the end-users. Hence, it is imperative to deliver the solution on time, and late delivery can undermine the very rationale for a project, especially where market opportunities or legal deadlines are involved.

Rationale: DSDM/AgilePM addresses common project risks by emphasizing on-time delivery through iterative development cycles and timeboxing. This approach ensures that the project stays on track and meets deadlines effectively. By focusing on delivering working solutions incrementally, the risk of late delivery is minimized.

Rationale: According to DSDM, the Team Leader plays a crucial role in ensuring that the team functions as a whole and meets its objectives. This involves coordinating all aspects of product delivery at a detailed level and working with the team to plan and execute tasks effectively. The Team Leader focuses on leadership rather than management, guiding the team towards achieving their goals collaboratively.

Rationale: The aspect of DSDM that is responsible for influencing the mindset and approach of a DSDM team is the Principles. In DSDM , principles are the core values that provide guidance on the fundamental values, approaches, and behaviors that underpin the whole DSDM approach. Adherence to the Principles ensures that the DSDM project team is aligned with the DSDM Philosophy and has the mindset that separates DSDM from other Agile frameworks. By following the principles, the DSDM team will be able to work effectively within the framework, producing results that adhere to the DSDM Philosophy.

Rationale: Measuring progress is one of the key aspects of managing a project, and different stakeholders measure progress for different purposes. Commonly, project measurement is used to understand enough about progress to allow the outcome to be controlled by making adjustments to keep the project on track. Other purposes of measuring progress may include enabling management to set performance targets, providing statistics to justify slippage, rewarding success or punishing failure.

Rationale: According to DSDM, Initial planning and prioritization should set the percentage of "Musts" at about 60%, which corresponds to MoSCoW prioritization. The "MoSCoW" technique is used for prioritizing requirements based on four categories: "Must Have," "Should Have," "Could Have," and "Won't Have." "Must Have" refers to critical requirements that are necessary to meet the project's objectives. DSDM suggests that rather than having an equal distribution of requirements in all four categories, Must-Haves should be prioritized by their business value. Teams should avoid having more than 60% of the requirements as Must-Haves unless there is a known accuracy in estimations, a well-understood approach, and a low-risk environment. Setting the number of "Musts" a little above that percentage can ensure that the project is capable of delivering essentials while having the flexibility to pivot based on feedback from stakeholders.

Rationale: DSDM focuses on developing a solution ensuring on-time delivery, which means delivering what the business needs when it needs it without compromising quality. This approach ensures that the project is driven by the principle of adaptability and responsiveness to changing requirements, making it a suitable choice for projects requiring flexibility and quick delivery.

Rationale: Provide an approximation of the size and duration of the overall project, based on what is known at this point, but this can only be an educated guess. Feasibility is the first stage in the DSDM process and is intended to provide a preliminary assessment of a project's viability and potential scope. By the end of the Feasibility phase, the team will have developed a basic understanding of the business vision, requirements, and solution to determine whether to proceed to the next stage of development, the Foundation phase. While it is possible to provide an estimation of the size and duration of the project, this is typically only an educated guess and must be revised as further details are uncovered in subsequent stages of development.

Rationale: During the Solution Development Team's structured Timeboxes, the team aims to grasp and validate Timebox objectives during the "Investigation" step. This is the first of the three steps within each Timebox, where the team undertakes a thorough Investigation of the current Timebox requirements, ensuring that every requirement is fully understood before considering its functional and non-functional parameters. Once the requirements are clarified, the team can proceed to determine the most viable and optimized approach to meet the objectives, along with a detailed plan of the implementation where each task is detailed, assigned, and prioritized.

Rationale: The main focus of DSDM testing (not the DSDM method as a whole) is validating the business solution. According to DSDM's Agile testing approach, the main goal of testing is to validate the business solution's quality and fitness for purpose. This process is designed to ensure that an Agile project delivers business value, focusing on doing the right thing, doing it right, and providing transparency to stakeholders throughout development. The Agile testing approach provides test cases that link back to the business requirements, ensuring that business benefits are realized. Through performing testing right from the beginning and including it within the sprint cycles, testing is involved right from project inception with an awareness and focus on quality. The Agile testing approach emphasizes that validating the business solution is the key objective of testing, ensuring the functionality of the software, security, performance, usability, and compatibility requirements are accurately addressed to meet the business needs.

Rationale: Configuring the DSDM lifecycle to optimise the delivery of early business benefits and risk mitigation is a key goal of the methodology. This is accomplished by using an iterative and incremental approach which seeks to deliver regular updates and improvements to the solution throughout the development lifecycle. By prioritising early delivery of business benefits, the team can help to ensure that the solution meets the needs of users and stakeholders while also mitigating risk by addressing issues early on when they are easier and less expensive to fix.

Rationale: The DSDM's approach and style have always been founded on an underlying ethos of common sense and pragmatism. This thinking style allows DSDM and DSDM Philosophy to avoid the dogma sometimes encountered in the world of Agile and ensures that "individuals and interactions" continue to take precedence over "processes and tools." This flexibility of thinking is particularly helpful when change is inevitable as the understanding of the solution grows over time. Therefore, pragmatism complements common sense and guides DSDM towards the consideration of practical consequences over theory or dogma.

Rationale: DSDM emphasizes the importance of active collaboration and commitment among team members to outperform loose associations of individuals working in silos. Collaborative teams encourage increased understanding, greater speed, and shared ownership, which enable them to perform at a level that exceeds the sum of their parts. DSDM teams implement this principle by involving the right stakeholders at the right time, empowering team members to make decisions, actively involving business representatives, and building a one-team culture. By collaborating effectively, DSDM teams can learn from each other, transfer knowledge, and apply learning from one project to the next for continuous improvement.

Rationale: Agile rules are important but existing corporate constraints must also be acknowledged. DSDM emphasizes the importance of adapting to changing business needs and using a flexible, iterative approach to solution development. However, DSDM also recognizes that many organizations have existing corporate constraints such as legal or regulatory requirements, project governance structures, or information security policies. While agile rules should be considered when developing solutions, existing corporate constraints must be taken into account in order to ensure that the solution is implemented in a way that is compliant with these requirements. By balancing the needs of the business with the existing constraints, the team can ensure that the solution is successful and meets the needs of all stakeholders.

Rationale: To be successful with DSDM, an organisation may have to change organizational, social, and technical elements at the same time. The DSDM approach requires collaboration and communication among the stakeholders, so it affects the organizational-social-technical domain simultaneously. To be successful with DSDM, the organization may have to change its technical infrastructure, work culture, project management processes, quality management processes, and various other aspects simultaneously. The focus should be on delivering solutions while ensuring the desired business value, providing much-needed flexibility and adaptability, and maintaining constant communication to keep everyone on the same page.

Rationale: The Delivery Plan is refined during the Foundations phase of the project which in turn is refined to create the individual Timebox Plans. This process involves breaking down the project's delivery schedule into specific timeboxes that focus on the detailed level of product delivery, ensuring a structured approach to achieving project milestones and objectives.

Rationale: The DSDM highlights the importance of setting fixed duration timeboxes for project activities to ensure on-time delivery is Timeboxing. This key practice establishes a short-term focus to meet project objectives in weeks or less creating a "right-sized" set of requirements based on the prioritization of business importance. In DSDM, the project team works together with business representatives to define, prioritize and refine requirements, and develop solutions that meet business objectives. Timeboxing ensures that the team only works on the right things, after carefully considering its priorities and business value. By adopting the Timeboxing technique in project activities' planning, teams can better manage project activities in various stages with reduced risk, and uncertainty, and, thus, increased business agility.

Rationale: The Technical Coordinator is responsible for ensuring that the Solution Development Teams work consistently, maintain technical coherence, and meet desired technical quality standards. This role advises on technical decisions, controls the technical architecture, and ensures the project's technical configuration. The Technical Coordinator plays a crucial role in aligning the project with technical best practices and standards.

Rationale: The 'Deliver on time' principle in DSDM supports organisations in achieving their business objectives, particularly by delivering products on time that align with market opportunities or legal deadlines. Late delivery can cause significant problems for an organisation, undermining its rationale for pursuing a project. DSDM recommends using timeboxing and MoSCoW prioritisation to focus on business priorities and hit deadlines, instil a reputation for timely and predictable deliveries, and deliver business benefits early, frequently and at a sustainable pace. By following this principle, organisations can achieve better business or financial outcomes, meet the scope, budget and schedule requirements, as well as keep stakeholders happy and engaged (yet not every project is for profit or finance gains, like non-profit projects or projects done by NGO organizations).

Rationale: Estimates need to include a level of contingency to allow for risks associated with unknown factors. DSDM, estimates are used to evaluate a Business Case, to assess feasibility, to establish a high-level plan, and to manage the project through to completion. However, the obvious factor is the most important, estimates are just that – forecasts (not predictions) of how long or how much is required to complete a piece of work. Because there is uncertainty associated with estimates, they need to include a level of contingency to allow for the risks associated with unknown factors. These include external environmental factors, unforeseen technical difficulties, changes to the scope of the work, etc.

Rationale: AgilePM integrates a project management lifecycle and a product development lifecycle into a single framework. This single framework is flexible and highly adaptable to any project domain. AgilePM refers to it as the lifecycle model, which guides the team on how to proceed from an idea to a deliverable product incrementally. The lifecycle model consists of six phases of the project management lifecycle (Pre-Project, Feasibility, Foundations, Evolutionary Development, Deployment, and Post-Project) and incrementally iterated and repeated product development lifecycle phases (Evolutionary Development, and Deployment).

Rationale: As per DSDM/AgilePM, the primary objective of identifying project risks is to reduce the potential negative impact of identified risks. Once the risks are identified, it allows the project team to take action proactively to mitigate the risks and minimize their impact on the project. Risk management is not about eliminating all risks but rather reducing the potential negative impact of those risks.

Rationale: Acceptance criteria are agreed upon and set before development commences. In DSDM, acceptance criteria are agreed upon at the outset to provide a clear definition of what is required for the project to be considered a success. This allows everyone involved in the project to understand the desired outcome and work towards that goal. Waiting until all requirements are completed or guaranteeing all features from the outset can lead to delays or even failure if there are misunderstandings or miscommunications about what is expected. Instead, establishing acceptance criteria from the beginning enables the team to continuously iterate and refine the solution based on feedback and changing requirements.

Rationale: Allowing the people doing the work to estimate is important because they have a vested interest in being right. In DSDM, team collaboration is important to estimating accurately. It is recommended that the people who will be doing the work provide estimates, because they have a better understanding of how much effort is required for the task, and it ensures that there is collective ownership and accountability for the estimation process. The people doing the work bring different perspectives and experiences to the estimation process. By involving them in the estimation process, different assumptions and risks can be identified and addressed before they become an issue.

Rationale: The DSDM/AgilePM methodology categorizes tests into two types: static and dynamic testing. Static testing examines the requirements documents and specifications for clarity, completeness, and consistency, while dynamic testing executes the software to uncover defects. Dynamic testing can be further categorized based on the approach taken and the expected results. Happy path testing validates the normal flow of the program, whereas negative testing verifies that the software handles invalid input gracefully. Unhappy path testing, sometimes referred to as error testing, is used to determine how the software might behave in the presence of exceptional events. Positive testing is not a recognized type of dynamic testing by DSDM/AgilePM methodology.

Rationale: The development of all 'must have' features" is not a correct statement. As per the DSDM methodology, the focus of a Development Timebox primarily lies in delivering at least the 'must have' features in a short period of time. This practice maintains focus on delivering in the short term and provides control at the lowest level. It is essential to ensure that the project is on track, the estimating process is correct, and risks are reduced. Therefore, the focus of a Development Timebox is to deliver at least the 'must have' features rather than all 'must have' features in a particular time frame. Other options given in the question are not relevant to the purpose of the Development Timebox.

Rationale: One of the basic rules of DSDM is that Timeboxes are not to be extended. Doing so goes against the principles of DSDM which encourages a steady pace of work with a predictable outcome. As such, renegotiating the end date of the Timebox is not ideal. Renegotiating the budget is also counter-productive since budgets have already been estimated before the project started. The preferred choice is to renegotiate the content of the Timebox (scope/features) to focus on delivering the minimum viable solution that meets the Must-Have requirements. If the team is still having difficulty arriving at a solution, then they can request a decision from the Steering Committee to help them prioritize the Must-Have requirements and come up with a satisfactory solution.

Rationale: The responsibility to prove a requirement is a Must Have lies with the Business Visionary. It is up to the Business Visionary or their empowered Business Ambassador to demonstrate that a requirement is indeed a Must Have. If they cannot prove it, then the requirement is considered a Should Have at best. The Business Visionary holds the ultimate responsibility for proving a requirement as a Must Have. They need to provide the necessary justification and evidence to show that a requirement is critical for the success of the project. This ensures that only truly essential requirements are classified as Must Haves, aligning with the project's objectives and priorities.

Rationale: In DSDM, delivering products on time is quite often the single most important success factor. Late delivery can undermine the very rationale for a project, especially where market opportunities or legal deadlines are involved. Therefore, delivering products on time is a very desirable outcome for a project in DSDM.

Rationale: Business representatives play a crucial role in DSDM by providing feedback and requesting changes during the development process. Their involvement ensures that the evolving solution aligns with business requirements and can be adjusted as needed. This iterative approach allows for continuous improvement based on real-time feedback from stakeholders.

Rationale: Contingency in estimations refers to a buffer time that can be used to handle unforeseen events. By including contingency time in estimations, the Solution Development Team can build in some flexibility to account for delays, unexpected issues, or other factors that may affect the project timeline. This helps ensure that the project stays on track even when things don't go entirely as planned.

Rationale: The emphasis of DSDM when using models for communication is clarity. DSDM recognizes that effective communication is a critical factor in project success. To ensure clarity in communication, DSDM emphasizes the use of models to improve communication and to create or challenge ideas by making developing products visible. DSDM's approach to modelling can range from very informal to very detailed, complex models using specific notations. Still, the emphasis is on ensuring that any models used enhance communication and are as clearly understood by the intended audience as by the creators. Developing models and prototypes is a process that ensures that the right people are involved, reducing the risk of errors, and ensuring that everyone understands the rationale of the model. The emphasis on clarity helps stakeholders to get a better understanding of the project, the benefits that come with it, and the best approach to solving any challenges that may arise. Overall, emphasizing clarity ensures effective communication and project success.

Rationale: DSDM refers to the "Minimum Usable Subset" as the smallest set of requirements that is still usable and valuable to the business before subsequent releases. The Must-have requirements take priority and are necessary for the solution to be usable, which can be delivered in the Minimum Usable Subset (MUS). The Should and Could requirements that add value to the solution should also be included in the MUST, but only after the Must-have requirements are covered. In other words, DSDM suggests that the MUST will include the essential requirements of the project and should not be viewed as the final product but rather, as the basis upon which continuous iterative development occurs.

Rationale: In a DSDM/AgilePM project, key points for setting the quality acceptance standard are identified during the Foundations phase. Foundations is one of the six phases of the DSDM lifecycle and is considered the most critical stage of the project since it sets the overall direction of the project. During the Foundations phase, the project team works to establish the project's approach, vision, objectives, scope, and context. The project team also identifies quality criteria for individual products and defines how these will be validated throughout the project. They ensure clear understanding and agreement on ways of working, priorities, deliverables, roles, and responsibilities, among other key items critical to the project's success. The quality criteria defined during this phase serve as the basis for acceptance criteria for each Increment, ensuring that the customer's expectations are fulfilled while maintaining the highest standards of quality. Once completed, the Foundations phase provides a clear baseline for the project and acts as the reference point for all subsequent stages of the project, including Iterative Development, Timeboxing, and Modelling, among others.

Rationale: The purpose of the Benefits Assessment is to provide a comprehensive account of how the benefits have accrued following a period of use in live operation. This product is a type of milestone product (or governance product), and it may be meaningful to review the benefits accrued per Increment and collate those into the assessment for the whole project. For projects where benefits in the Business Case are expected to accrue over a prolonged period, several Benefits Assessments may be produced periodically aligned with the timeframe used for justifying the investment.

Rationale: DSDM, emphasizes managing change through constant refinement of the product based on quick and sure decisions. The Iterative Development cycle enables the team to deliver a product fit for its intended purpose by the end of a Timebox. Team members are empowered to handle changes within the current scope without formal change control processes. The DSDM approach ensures that changes are dealt with swiftly to avoid time wastage or loss. Significant changes impacting scope may require a more formal change control process, while negotiation around the details of the solution can generally be handled within the empowered team. The Solution Development Team operates within certain tolerances without escalating changes to higher project-level roles.

Rationale: The purpose of identifying dependencies during the Kick-Off meeting of the Timebox is to ensure smooth progress and timely delivery of the Timebox to minimize risks. Identifying dependencies helps the Solution Development Team to understand what work needs to be done and in what order so that they can prioritize and schedule tasks effectively. Additionally, identifying dependencies helps mitigate the risk of delays or setbacks by addressing potential roadblocks between the teams before they become problematic. On a side note, the Project Manager is not responsible for planning at a low level, i.e. Making Timebox Plans is the responsibility of the Team Leader.

Rationale: DSDM proposes that Project Managers and Team Leaders should use collaborative techniques, such as Facilitated Workshops, for planning. This ensures buy-in and ownership of the plans, making planning more effective. Collaborative planning techniques like Facilitated Workshops help in creating detailed plans with input from key roles in the project team.

Rationale: In a free-format Timebox, reviews, as with all other Agile project methodologies, are critical to maintaining stakeholder buy-in and managing business focus. The DSDM framework emphasizes continuous improvement and adapting processes based on feedback. To achieve this, it is important to review progress throughout the Timebox rather than at its end. The timely reviews fit in well with the iterative development process of Agile that involves constant feedback, adapting to changing requirements, and delivering valuable increments of the product. Regular reviews help teams identify changes or modifications that might need to take place and accept these in a timely way.