Assessment

The assessment for Phase 1 aims to evaluate participants' understanding and application of the core Agile principles, concepts, and practices introduced in the initial sessions. This assessment combines multiple-choice questions, short-answer questions, and practical tasks to ensure a comprehensive evaluation of participants' knowledge and skills.

Assessment Structure

Multiple-choice questions (MCQs)

Purpose: Test participants' grasp of fundamental Agile concepts and terminology.

Format: Each question has four options, with one correct answer.

Total Questions: 10

Example Questions:

What is the primary purpose of Agile methodologies?

a) Increase project cost b) Deliver customer value faster c) Extend project deadlines d) Minimise stakeholder involvement

Which of the following is a key principle of the Agile Manifesto?

a) Process over people b) Comprehensive documentation c) Customer collaboration over contract negotiation d) Following a plan strictly

In Scrum, who is responsible for maximizing the value of the product?

a) Scrum Master b) Product Owner c) Development Team d) Stakeholders

Short-Answer Questions

Purpose: Assess participants' ability to articulate key Agile principles and practices in their own words.

Format: Participants provide brief written responses.

Total Questions: 5

Examples:

Briefly describe the concept of "iterative and incremental work" in Agile. Explain the role of the Iteration/Scrum Master in an Agile team. What is the significance of a "Definition of Done" in Agile projects? How does visualising work (e.g., using whiteboards or digital tools) benefit Agile teams? Describe a retrospective and its importance in the Agile process.

Practical Tasks

Purpose: Evaluate each team’s ability to apply Agile concepts in practical scenarios.

Format: Scenario-based tasks requiring participants to demonstrate their skills. The coach will conduct these by attending at least one of each team's ceremonies throughout the training.

Total Tasks: 3 (Minimum 1)

Example Tasks:

Scenario 1: Sprint Planning

Your team is about to start a new sprint. Outline the steps during the sprint planning meeting and explain how you would ensure the team understands the sprint goals and backlog items.

Elicitation

Does the team understand what the work is and, through problem-solving, break it down into smaller pieces?

Elaboration

Does your team have a way of understanding the detail and how the work will be done?

Risk Management

Incorporating risk identification, analysis, response and monitoring and controls

How are your team's risk management practices?

Risk identification and management don't occur. No risk registers. Risks are spoken to in ceremonies but not recorded. Potential problems are not spoken about as a risk. Risk management is an afterthought or 'bolted-on'.
The team keeps a risk register. The risk register is sporadically updated. Some actions are captured to address serious/critical risks. Risks have been identified and are captured using appropriate artefacts such as Risk Story Walls, Big Visual Charts (BVC), a Risk Register, etc. Risks are identified by an appropriate group of stakeholders (i.e. not just the project manager or the team leader in isolation). Risk artefacts are 'owned' by the team, and team members have no reservations about making contributions or changes. Each identified risk has been assigned a risk m•tigation or action plan. Risk mitigations and action plans are a strategy, process or action (i.e. something that can be done). Risks are considered when implementing changes or new systems, processes, products, etc.
Risks are visualised on a risk matrix in the team area or easily viewable. The risk matrix is reviewed and updated as part Of the DOD for the iteration. Each risk identified has an appropriate risk management approach (Mitigate, Contingency, Transfer, or Accept). Risks, issues and blockers are discussed in appropriate detail as part Of all sessions (stand-ups; iteration planning; showcases; steering committee meetings; etc.). Risk mitigations and action plans are treated like any Other activity or feature; they are represented by individual story cards, included in iteration planning and tracked and completed during the iteration. Unmitigated or uncontrolled risks are easily identifiable. Risks, controls and action plans are assigned to appropriate owners; someone who understands the risk has responsibility and accountability for managing the risk, has an interest in the risk, and has the authority to implement controls/actions. Leaders support the identification of risk and risk management activities.

Dependency Management

How are your team's dependency management practices?

The team keeps backlog items open for multiple cycles while an external team resolves dependencies. Controls and permissions are limited to a few people. Work is tightly coupled.
The team splits backlog items if there is an external dependency and brings it into the backlog for completion later. The team uses simulated data or interfaces to make progress. They use Scrum of Scrums to visualise and monitor dependencies.
The team has the time and focus to earnestly start to cross-train so they can own more Of the work themselves. They start to resolve complexities in their tech stack and architecture. The team has everyone and everything they need to finish the work. They don't accept work with open dependencies. Only critical permissions and controls are restricted. Work is loosely coupled.

Last updated 7 months ago

Was this helpful?

Risk Management

Incorporating risk identification, analysis, response and monitoring and controls

How are your team's risk management practices?

Risk identification and management don't occur. No risk registers. Risks are spoken to in ceremonies but not recorded. Potential problems are not spoken about as a risk. Risk management is an afterthought or 'bolted-on'.

The team keeps a risk register. The risk register is sporadically updated. Some actions are captured to address serious/critical risks. Risks have been identified and are captured using appropriate artefacts such as Risk Story Walls, Big Visual Charts (BVC), a Risk Register, etc. Risks are identified by an appropriate group of stakeholders (i.e. not just the project manager or the team leader in isolation). Risk artefacts are 'owned' by the team, and team members have no reservations about making contributions or changes. Each identified risk has been assigned a risk m•tigation or action plan. Risk mitigations and action plans are a strategy, process or action (i.e. something that can be done). Risks are considered when implementing changes or new systems, processes, products, etc.

Risks are visualised on a risk matrix in the team area or easily viewable. The risk matrix is reviewed and updated as part Of the DOD for the iteration. Each risk identified has an appropriate risk management approach (Mitigate, Contingency, Transfer, or Accept). Risks, issues and blockers are discussed in appropriate detail as part Of all sessions (stand-ups; iteration planning; showcases; steering committee meetings; etc.). Risk mitigations and action plans are treated like any Other activity or feature; they are represented by individual story cards, included in iteration planning and tracked and completed during the iteration. Unmitigated or uncontrolled risks are easily identifiable. Risks, controls and action plans are assigned to appropriate owners; someone who understands the risk has responsibility and accountability for managing the risk, has an interest in the risk, and has the authority to implement controls/actions. Leaders support the identification of risk and risk management activities.

Dependency Management

How are your team's dependency management practices?

The team keeps backlog items open for multiple cycles while an external team resolves dependencies. Controls and permissions are limited to a few people. Work is tightly coupled.

The team splits backlog items if there is an external dependency and brings it into the backlog for completion later. The team uses simulated data or interfaces to make progress. They use Scrum of Scrums to visualise and monitor dependencies.

The team has the time and focus to earnestly start to cross-train so they can own more Of the work themselves. They start to resolve complexities in their tech stack and architecture. The team has everyone and everything they need to finish the work. They don't accept work with open dependencies. Only critical permissions and controls are restricted. Work is loosely coupled.