Symulator egzaminu AgilePM® V2 Foundation

Rationale: In DSDM, testing is prioritized based on risk assessment. This means that the areas of functionality that involve the greatest risk to the project or business are given the highest testing priority. The risk assessment is typically performed during the Foundations phase and is reviewed and updated throughout the project as required. Under DSDM, the early and continuous involvement of stakeholders ensures that testing is carried out with the ultimate goal of delivering a high-quality product that meets the needs of stakeholders. By prioritizing testing based on risk, teams can ensure that they are focusing their efforts on the areas that matter most, thus increasing the chances of project success.

Rationale: The Timebox Review Record is created to document achievements and feedback at the review points in the Development Timebox. It captures what has been achieved, any feedback that may influence future plans, and any outstanding issues that need to be addressed. This record serves as a formal documentation of the success of delivery against the Timebox plan and the acceptance of Timebox deliverables by the business representatives.

Rationale: The total business value is stated in the Business Case and may be broken down into different elements. In AgilePM, the Business Case is a key document, owned by the Business Sponsor, that provides justification for the project. It outlines a quantified estimate of the costs and benefits associated with the project, including a cost and benefit analysis in line with organizational guidelines, and describes how the benefits will accrue and be measured. The Business Case provides the financial and other justification for the project, including a potential breakdown of the benefits by different categories. This total value - and any breakdowns within it - should reflect the desired outcomes from the investment and concisely demonstrate why the solution is worth delivering.

• The Prioritised Requirements List (PRL) describes, at a high level, the requirements that the project needs to address if the Business Case is to be met.
• The Delivery Plan is a high-level plan that includes the time-boxed periods (Timboxes) to deliver the agreed Solution.
• The Project Approach Questionnaire (PAQ) is a document that allows a project team to establish a common understanding of how they will deliver a solution to meet stated needs.

Therefore, neither the PRL, the Delivery Plan, nor the PAQ would include the total business value or breakdown of different elements - that information is stated in the Business Case.

Rationale: During the Feasibility phase in AgilePM, initial estimates are high level and are done "top down." At this stage in the project, requirements are high-level and few, so estimating cannot be precise. The main purpose of initial estimates during Feasibility is to support the Business Case by giving outline costs and timescales for the project.

Rationale: The key factor that drives the prioritization of features in DSDM/AgilePM projects is the consideration of business benefits on time. Prioritizing features based on their alignment with the overall business goals and expected benefits ensures that the project delivers value to the organization. By focusing on business benefits, DSDM/AgilePM projects can optimize the use of resources and time to deliver the most impactful features first, enhancing the project's success and value proposition.

Rationale: Modelling, as part of AgilePM's drive for clear and continuous communication, offers significant benefits in making ideas, situations, and options visible. It helps in enhancing communication by creating visual representations that aid in understanding and challenging ideas effectively.

Rationale: The Business Ambassador works closely with the Solution Development Team to guide the evolution of the solution based on business needs. Their role is to provide the business perspective for all decisions related to defining and implementing the solution.

Rationale: The vertical approach slices through multiple layers of the solution with each Timebox delivering one or more fully functional features, whereas the horizontal approach considers the solution layer by layer with each Timebox delivering horizontal slices of the solution.

Rationale: If an Agile team is upholding the 'Never compromise quality' principle, they should design, document and test appropriately. This means that quality should be built into the product at every stage of the project lifecycle, with appropriate design, documentation, and testing practices followed to ensure that the final product meets all required quality standards.

Rationale: The role in AgilePM that provides specialist input to solution development or testing is Business Advisor. The Business Advisor is an integral part of the Solution Development Team and is often a peer of the Business Ambassador. They provide specific, and often, specialist input to solution development or solution testing, thereby ensuring that the business needs are properly analyzed and reflected in the guidance the team needs to generate the solution. Therefore, the Business Advisor is responsible for providing expert advice and insights to the Solution Development Team, helping ensure that the solution aligns with the business requirements.

Rationale: The AgilePM principle of "Demonstrate Control" advocates for control at the lowest level, which is the Development Timebox. The preparation of the Management Foundations and Timebox Plans assists the Project Manager and the AgilePM team in demonstrating control. The detailed planning typical of these documents combined with the close monitoring and dynamic control of the project during a timebox, both support and demonstrate control. The plans provide essential information for project team members to deliver their work effectively, reducing surprises, and encouraging realistic goal setting. By actively demonstrating control, the project team can balance flexibility with the need to deliver business benefits while focusing on the timely completion of project objectives.

Rationale: Choosing the wrong or inappropriate approach to project management can significantly escalate the risks involved, leading to potential negative impacts on the project's success and outcomes. Following an incorrect project management approach can introduce uncertainties, delays, and inefficiencies, thereby increasing the overall risks associated with the project. This can result in missed deadlines, unclear requirements, and reduced chances of delivering a successful solution. By adhering to the appropriate project management methodology like DSDM/AgilePM, risks can be minimized, ensuring a higher probability of project success.

Rationale: In a small AgilePM team working with clear objectives in Development Timeboxes of short duration, there will be no need for complex and bureaucratic monitoring systems. This approach allows for focused work within set timeframes (Timeboxes with clear goals set during Kick-Off sessions), promoting efficiency and transparency in project progress without the need for extensive monitoring mechanisms.

Rationale: Defining tests upfront and sharing those tests collaboratively with whoever is building the feature to be tested can help identify the highest-value tests so that the Solution Development Team can better prioritize testing activity. This ensures that the most critical aspects of the solution from a quality perspective are given the appropriate attention.

Rationale: The MoSCoW prioritization is used to categorize project requirements into Must Haves, Should Haves, Could Haves, and Won't Haves. It is important to note that a Must Haves requirements are essential to delivering a working product. In Agile Project Management, Must Haves have the highest priority and are the most crucial elements of the product to be delivered in any increment. According to the AgilePM, any effort above 60% for Must Haves introduces a risk of failure, unless the team is working on a project where estimates are known to be accurate, the approach is well understood, and the environment is low-risk in terms of external factors introducing delays. Therefore, allocating <60% of the effort to Must Haves should ensure the project's success while providing flexibility in the product delivered.

Rationale: The assertion regarding late delivery that aligns with DSDM/AgilePM is that "it can frequently undermine the purpose of a project." By definition, DSDM/AgilePM 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: The phase of the AgilePM Lifecycle that is typically planned to be shorter than in a traditional one-delivery project is Feasibility. The Feasibility and Foundations phases are sequential phases in AgilePM, starting after the Pre-project activity has been completed. These two phases are usually shorter than in a traditional one-delivery project. AgilePM recommends allowing for just enough design upfront and planning incrementally. These phases allow the Project Manager to determine the requirements and design processes needed to accomplish the project's goals. The project manager, with the Solution Development Team, assesses work done in the Feasibility and Foundations phases to determine the appropriate approach to accomplish the project's goals.

Rationale: Agile projects rely on daily stand-up meetings to keep everyone informed and updated. During these meetings, every team member should be ready to discuss the work they completed since the last meeting, what they plan to work on, and if any issues could affect heading towards the next milestone. These meetings facilitate information sharing and problem-solving by the team. This gives everyone involved a clear idea of what is being worked on, where the issues are, and who is responsible for what. The main objective of the stand-up meeting is to improve efficiency, reduce risk, and address potential roadblocks that might hamper the project's progress. Stand-up meetings also encourage transparency, accountability, and team collaboration. Therefore, AgilePM primarily emphasizes that everyone concerned with the development team is aware of what is happening because every day begins with a full review of the status of the whole project through stand-up meetings, where team members share their updates, work, and problems, enhancing communication and teamwork.

Rationale: The main risk of exceeding 60% effort on Must-Haves in a project is decreased predictability. The AgilePM notes that levels of effort above 60% for Must Haves introduce a risk of failure unless the team is working on a project where estimates are known to be accurate, the approach is well understood, and the environment is low-risk concerning the potential for delays caused by external factors. If the team exceeds 60% of the effort on the Must Haves without taking into account the appropriate environmental factors, it may lead to changes in priorities, time, and cost estimates, which can result in the failure of the project and decreased predictability. Therefore, the AgilePM recommends that the team should maintain a balance between the level of effort and time, based on the risk level and impact.

Rationale: The Won't Have this time category is used to include items that the Solution Development Team plans to leave out in a specific Timebox when prioritizing requirements. An item that falls into the Won't Have this time category might be deferred to a future iteration, or the project as a whole.

Rationale: According to DSDM/AgilePM, 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: At the outset of the project, Agile/DSMDM methodology acknowledges that the requirements will be high-level and potentially subject to change during the project's lifecycle. The organization requires that initial requirements be defined in the Feasibility stage, after which, during the Foundations phase, those requirements should be turned into more detailed specifications. The initial requirements act as a springboard that the team can refine and enhance during the Foundations phase. A key consideration is recognizing that the detailed requirements emerge from the higher-level ones, allowing the team to keep its creativity while still delivering value to the end customer. By embracing an agile approach to requirements, the team remains flexible to changing customer needs and market changes

Rationale: "Build customer feedback into each iteration", which supports the principle of 'Build incrementally from firm foundations' in DSDM. This principle emphasizes that products should be developed gradually and iteratively with a focus on delivering a fully functional solution incrementally. By building customer feedback into each iteration, the team can develop a product in a more dynamic and customer-oriented manner. It reduces the risk of delivering an end product that does not meet the customer's expectations.

Rationale: The key advice given to project managers regarding the visibility of lifecycle phases and the project as a whole visible to the Solution Development Team is to "Keep them visible." The AgilePM emphasizes that the Solution Development Team should be made aware of the phases of the lifecycle during the project. This provides transparency and visibility into the phases of the project, what needs to be accomplished, and what work has already been done. Keeping the lifecycle phases visible throughout the project provides clarity on the work already accomplished, what work is needed in the future, and how each phase contributes to the overall project outcome.

Rationale: Business representatives play a crucial role in AgilePM 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: The Project Approach Questionnaire (PAQ) is a simple management product that helps to identify and confirm the level of achievement of all the relevant factors and to assess potential risk areas to be addressed. The PAQ is used at the very beginning of the AgilePM lifecycle to ensure that all team members have a shared understanding of the project objectives, requirements, constraints, and risks. The PAQ is completed collaboratively by the project team, including the Business Ambassador, Business Visionary, Business Analyst, Technical Advisor, Team Leader, and Solution Tester, and it is used throughout the project to guide decision-making and risk management.

Rationale: Automated tests are a commonly used testing practice, where tests are performed using software tools (or scripts) instead of being executed manually to validate that the software functions as expected. Automated testing is very effective when dealing with precise inputs and predictable outputs in a solution. This means that tests where the expected output is known before running the test are suitable for automation. Automated testing can be very beneficial when testing solutions with a large amount of data, as it can speed up the testing process and reduce testing errors. Those types of tests minimize the risk of human error, which is likely to occur during repetitive tasks.

Rationale: Projects typically begin with Pre-Project activities aimed at describing a business problem to be addressed, identifying a business sponsor and visionary, and confirming that the project is in line with the business strategy. This is followed by a Feasibility phase that assesses the viability of the project from both a business and technical perspective. Once the Feasibility phase is complete, the project proceeds to the Foundations phase which establishes a shared understanding of the project objectives, scope, risks, and success criteria between the business and technical staff. The Evolutionary Development phase comes after the Foundations phase, where the solution is incrementally developed and tested. The post-Project phase comes into play covering activities such as keeping the solution operating effectively and checking that the expected business benefits have been achieved.

Rationale: Breaking any of the DSDM's principles poses a significant risk to the success of both the agile process and the project. Adhering to the principles is vital as these principles serve as the guiding philosophy for DSDM, shaping the team's attitude and behaviour. Adhering to and promoting the principles is the agile way of delivering best-value business solutions collaboratively. The principles collectively deliver greater value than their individual benefits, and compromising any of the principles undermines DSDM's philosophy.

Rationale: The AgilePM 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 AgilePM, 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 AgilePM Lifecycle is highly configurable and is sequential for Pre-project, Feasibility, and Foundations phases. However, it allows for many iterations of Evolutionary Development and many separate Deployments. The AgilePM recommends planning incrementally, which means adjusting plans as the project progresses, allowing flexibility in the project's approach, and ensuring that the project manager delivers business value early and demonstrates progress.

Rationale: The Business Advisor role is someone who is often a peer of the Business Ambassador and who is called upon to provide specific, and often, specialist input to solution development or solution testing. The handbook notes that the Business Advisor will normally be an intended user or beneficiary of the solution, but may, for example, simply provide legal or regulatory advice with which the solution must comply.

Rationale: The Agile Project Manager focuses on motivating and supporting empowered teams in AgilePM projects. They avoid micro-managing at a task level and instead ensure that the team follows Agile best practices for successful project delivery.

Rationale: Detailing the Business Case for the project is an essential aspect of the work of the Feasibility and Foundations phases in the AgilePM Lifecycle. During the Foundations phase, the justification for the project is evaluated, and a decision is made about whether to proceed with it. Detailing a Business Case is essential in the Foundations phase, and it helps to assess the viability of the project, its benefits, costs, and potential risks. In contrast, the Deployment phase focuses on delivering the solution into production and supporting it after release; the Foundations phase aims at creating a high-level view of the project, and the Pre-Project phase is for preparing the groundwork for the project.

Rationale: The Timebox Plan is based on estimates created at the task level, and therefore, the correct statement is that the level of uncertainty is lower, and the accuracy is higher. In AgilePM, the whole project is not planned out in full at the beginning but is instead broken down into a series of Timeboxes. Each Timebox Plan is created based on the task estimations providing a more detailed level of task planning, therefore, reducing the level of uncertainty and increasing the accuracy of the plan. The aim is to plan in detail for the next phase and to plan in outline for phases that are further away. This is because the next step is fairly predictable, and detailed plans are more likely to stand the test of time, whereas stages further in the future will have less certainty and are far more likely to change. The Timebox creates a measure to show whether the higher-level plans are at risk, and by assessing the impacts at the end-of-refinement review, the Project Manager and the development team will have a higher level of confidence as to what is going to be delivered by the end of the Timebox.

Rationale: According to AgilePM, the Technical Advisor resolves technical differences between technical team members. This role provides technical expertise, identifies technical risks and fixes, and ensures that non-functional requirements are reflected in the guidance to generate the solution. They oversee the technical configuration of the solution, ensure that the non-functional requirements are achievable and subsequently met, and ensure adherence to appropriate standards of technical best practice.

Rationale: AgilePM can incorporate other agile delivery approaches like extreme Programming (XP) and SCRUM to provide a comprehensive agile management framework. This integration enables the controlled delivery of agile projects by leveraging different agile methodologies to ensure successful project outcomes.

Rationale: AgilePM takes an evolutionary approach to planning. This approach involves creating a detailed plan for the next phase while creating an outline plan for the later steps. In AgilePM, plans evolve as the understanding of the requirements deepens and the level of uncertainty decreases. The aim is to plan in detail for the next phase and to plan in outline for phases that are further away. This is because the next step is fairly predictable, and detailed plans are more likely to stand the test of time, whereas stages further in the future will have less certainty and are far more likely to change. Creating very detailed plans for phases that are more than a few weeks into the future is wasted time and effort. It can also create a false sense of security since creating a detailed plan does not show the true level of uncertainty associated with future phases. In contrast, an evolutionary approach provides the flexibility to respond to changing circumstances and to incorporate new information into planning as it becomes available.

Rationale: The product that outlines the accomplishments of a Timebox and incorporates feedback for future planning is the Timebox Review Record. This product records the progress made during a Timebox, as well as any approved changes or deviations from the original plan. It incorporates feedback from relevant stakeholders, including the customer, development team, business representatives, and review team. The review team uses the Timebox Review Record to evaluate whether the Timebox has met its objectives, whether the completed increment meets acceptance criteria, and to identify areas for improvement in future Timeboxes. Any progress reports and Delivery Plans are significant documents in the AgilePM/DSDM framework, but they are not used to outline the accomplishments of a Timebox and incorporate feedback for future planning.

Rationale: The DSDM Coach should ideally be certified as a DSDM Coach to ensure competence to fulfil this role has been independently validated. The DSDM Coach provides support, guidance, and training to Project Team members to assist them in fulfilling their roles effectively and ensuring adherence to the DSDM Framework. They provide an independent and objective view of progress and the project as a whole throughout its lifecycle. Hence, it is essential for the person to have the necessary competencies to perform the role effectively, which can be validated by being certified as a DSDM Coach.

Rationale: Models and prototypes can help to analyze and present some of the required technical information in manageable Increments. They can be used to establish and confirm requirements, test the feasibility and achievability of objectives, and present some of the required technical or architecural information. Models, in general, help to represent a complex system, idea, or situation in simplified and easily digestible forms. This makes it easier for the intended audience to understand and communicate the information effectively.

Rationale: The Business Analyst ensures that the business needs are properly analyzed and are correctly reflected in the guidance the team needs to generate the solution. In AgilePM methodology, the Business Analyst is fully integrated with the Solution Development Team and responsible for facilitating communication and collaboration between the business and the technical roles. The Business Analyst acts as the link between the Solution Development Team and the business stakeholders, ensuring that the solution meets the business requirements, benefits, and quality criteria.

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 goal of the DSDM/AgilePM Deployment phase is to offer the broader organization an initial glimpse of the solution they will ultimately utilize. During this phase, selected, prioritized and tested Increments of the solution are deployed, typically into live use, providing an opportunity for stakeholders to gain an early view of the solution. The users are broadly representative of the wider user community, and their feedback is considered and weighted appropriately, thereby providing an opportunity to fine-tune the solution.

Rationale: Scalability is one of the key attributes of DSDM/AgilePM that enables the method to be tailored for a wide range of project sizes, scopes, and complexities. AgilePM framework can scale up or down depending on the demands of the project, different team structures, organisational cultures, and development environments. AgilePM defines different techniques and approaches that can be used to optimise the delivery of projects of different sizes and criticality, and this is made possible by the scalable nature of the method. Therefore, AgilePM recognises that a single development approach does not fit all projects, and it provides a scalable approach to adapt to the needs and requirements of different projects.

Rationale: Testing should be conducted as early as possible, according to the DSDM principle to ensure that defects are identified and fixed promptly. By testing early, the team can address issues sooner, reducing costs and improving the overall quality of the deliverables.

Rationale: AgilePM's approach is based on the idea that Time, Cost, and Quality are fixed and contingency is built around the prioritisation of Features. If the business needs all features to be delivered, contingency must be built into Time and/or Cost instead. AgilePM provides a framework for prioritising features/requirements called MoSCoW to help prioritise which features are most important to meet the needs of the business. However, in some cases, the delivery of all identified features may be a higher priority and cannot be achieved by merely dropping lower-priority features without compromising the solution's viability. In such cases, contingency must be managed by utilising additional resources or extending the delivery time, which will impact Time and/or Cost. Therefore, in order to deliver the entire scope of features demanded by the sponsor, it is essential to ensure that business cases are developed regularly to verify that additional resources can be allocated, or the timeline can be extended to accommodate the expansion of the project's scope while still maintaining the required quality standard.

Rationale: Agile promotes Enough Design Up Front (EDUF). This approach emphasizes striking a balance between having sufficient initial design to establish strong foundations for the project while allowing for flexibility and adaptation as the project progresses. It encourages early delivery of business benefits, continual confirmation of the correct solution, and formal reassessment of priorities and project viability with each increment.

Rationale: The success factors that greatly improve the success of a Facilitated Workshop include having an effective independent Workshop Facilitator, flexibility in the format while maintaining clearly defined objectives, thorough preparation by the Facilitator and Participants before the Workshop, ensuring decisions and agreements are not forced, providing a mechanism for integrating outcomes from previous workshops, and sending a Workshop report to Participants soon after the Workshop has occurred. It is not always possible for Participants to agree on every point discussed during the workshop due to various reasons such as lack of information, inadequate time, and conflicting opinions. In such cases, the Workshop Facilitator should recognize the outcome and elicit from the group the appropriate action to remedy the shortfall.

Rationale: DSDM/AgilePM takes an empowered team approach to task allocation and control, enabling team members to work collaboratively and make collective decisions. In this approach, team members are self-organizing and work together to determine who does what and how. This approach fosters creativity, and innovation and allows team members to use their skills and knowledge to accomplish their tasks most effectively. Although individuals may be responsible for specific tasks, team members are encouraged to take on a broader perspective and work together to accomplish team goals. The team's ethos is participatory, not hierarchical or directive, and fosters continuous communication among team members to ensure effective collaboration.