Select Two (Multi-Select) Questions

Strict WIP limits.

Strict WIP limits cap concurrent work per person or column, forcing completion before pulling new items. This directly reduces context switching by preventing the multi-tasking that fragments focus, satisfying the stem's constraint of minimising task-switching overhead across the team.

Focusing on one feature at a time.

Working on a single feature limits the number of active work items, so the brain does not repeatedly reload different task contexts. This directly reduces the cognitive reload cost and queueing delays that context switching creates, satisfying the stem's goal of minimising switching across the team.

Scheduling dedicated time for deep work.

Reserving uninterrupted blocks prevents fragmentation of the working day, so developers are not forced to interleave unrelated tasks. Fewer interruptions mean fewer context reloads, directly satisfying the stem's requirement to minimise context switching through deliberate scheduling of continuous focus periods.

Automated deployment.

Automated deployment moves validated builds into environments without manual intervention, removing handoff delays and human error. This keeps the pipeline flowing continuously from commit to release, satisfying the requirement for a healthy, continuous delivery pipeline.

Continuous integration.

Continuous integration merges developers' changes into a shared trunk frequently, with each merge triggering automated build and verification. This detects integration defects early and keeps the codebase releasable, directly supporting the continuous flow a healthy delivery pipeline requires.

Automated testing.

Automated testing runs regression and acceptance checks on every change without manual effort, giving fast feedback on quality. This prevents defects progressing downstream and keeps the pipeline trustworthy, satisfying the requirement for a healthy, continuous delivery pipeline.

Archive or remove low-priority items that are unlikely to be built.

Archiving or deleting low-priority items that are unlikely to be built shrinks the backlog to a manageable, decision-ready size. It removes stale entries that distort prioritisation and inflate refinement effort, keeping the remaining items ordered and genuinely actionable.

Regularly refine and prioritize the backlog with the Product Owner.

Continuous refinement with the Product Owner keeps the backlog ordered by value and prunes stale items, directly addressing the stem's constraint of an oversized backlog. This collaborative practise prevents low-priority work accumulating, ensuring the team always pulls the highest-value stories.

Encouraging the team to experiment with both options in a time-boxed sprint.

A time-boxed experiment lets the team generate real evidence about each architecture's trade-offs instead of debating opinions. It satisfies the conflict constraint by converting an abstract disagreement into observable results, after which the team can decide on demonstrated behaviour rather than seniority or persuasion.

Facilitating a data-driven evaluation of the proposed architectures.

Facilitating data-driven evaluation replaces opinion-based advocacy with measurable criteria such as latency, cost, scalability and maintainability. This satisfies the architecture-conflict constraint by giving both camps a shared, objective basis for comparison, so the decision rests on evidence rather than the loudest voice.

Cycle Time.

Measures the time to complete a single unit of work.

Throughput.

Measures the volume of work completed over time.

Lead Time.

Measures the time from request to completion.

Trust the team to make their own technical and process decisions.

Trusting the team to make their own technical and process decisions directly enables self-organisation, satisfying the stem's empowerment requirement. Authority over both technical and process choices shifts from leader to team, which is the defining mechanism of self-organising teams in agile practise. Without delegated decision rights, empowerment remains nominal.

Set clear objectives and constraints, then let the team decide how to meet them.

Setting clear objectives and constraints while delegating method decisions gives the team autonomy over execution, satisfying the self-organisation requirement. This boundary-based empowerment lets members plan and coordinate their own work, rather than receiving task-level direction, which is precisely what distinguishes a self-organising team from a merely compliant one.

Provide the necessary resources and remove organizational impediments.

Supplying resources and clearing organisational impediments directly enables self-organisation by shifting authority to the team, satisfying the stem's empowerment constraint. A leader who removes blockers rather than directing work lets the team own decisions and delivery. This matches PMI-ACP servant-leadership, where the leader serves the team instead of commanding it.

Business value/benefit.

Business value states the benefit a story delivers, letting the team prioritise by customer impact rather than technical effort. It satisfies the stem's requirement for a typical user story component, alongside the role and goal. This makes it a standard element in PMI-ACP story formatting.

User role.

A user story names its user role, identifying who receives the value and anchoring the narrative's perspective. This satisfies the stem's requirement for the 'as a...' component that specifies the persona or actor the functionality serves.

Desired functionality.

Desired functionality captures what the user needs the system to do, forming the core narrative of a user story. It satisfies the stem's requirement for typical inclusions, alongside the role and the benefit or business value. Without it, the story lacks a testable feature description for the team to implement.

Coaching team members to reach their full potential

Coaching team members to reach their full potential embodies servant leadership by prioritising followers' growth over the leader's authority, satisfying the stem's requirement for a servant leadership example. The leader removes impediments and develops people, rather than directing tasks, which aligns with the agile principle of enabling self-organising teams.

Removing obstacles that hinder the team's progress

Removing impediments directly enacts servant leadership by shifting the Scrum Master's focus from directing work to enabling it. This satisfies the stem's requirement for a servant leadership example because the leader serves the team's need for unblocked flow, clearing organisational or technical barriers rather than assigning tasks or commanding delivery.

Modeling the values and behaviors you expect from the team

Modelling expected values and behaviours demonstrates servant leadership by influencing through example rather than positional authority, satisfying the stem's requirement for a servant leadership practice. Leaders who visibly embody the standards they set remove the "do as I say" dynamic, earning trust and enabling the team to self-organise around shared norms.

Scrum Master or Team Facilitator.

The Scrum Master serves the team by removing impediments, coaching agile practises and shielding it from external disruption, directly enabling self-organisation. This facilitation role is fundamental because without it the team's process discipline and continuous improvement stall, undermining the collaborative cadence the scenario demands.

Product Owner.

The Product Owner owns the backlog and maximises value by ordering work and defining what gets built. This role is fundamental because it supplies the single, prioritised direction the team needs; without it, developers lack clarity on value and the team drifts into output without purpose.

The team feels comfortable asking for help when they are stuck.

Openly asking for help shows the team trusts collective ownership over individual image, a hallmark of self-organisation. This behaviour satisfies the question's signal because members prioritise delivering value over appearing self-sufficient, enabling work to flow without manager intervention.

The team adjusts their own working agreements based on retrospective findings.

Self-organisation requires the team to own its process, not just follow imposed rules. Adjusting working agreements from retrospective findings shows the team inspecting its own practices and adapting them without a manager or coach directing the change, satisfying the stem's demand for evidence of genuine self-organised behaviour.

The team proactively identifies and addresses process blockers.

Self-organised teams own impediment removal rather than escalating every blocker to a manager or scrum master. Proactively identifying and addressing process blockers demonstrates the team taking collective responsibility for its workflow, which is the specific self-organisation behaviour the stem asks you to recognise.

Encouraging members to challenge ideas

Inviting challenge normalises dissent, so members speak up without fear of retribution. This directly builds the shared belief that raising concerns or contradicting senior voices is safe, which is the core of psychological safety in agile teams.

Supporting experimentation and learning

Supporting experimentation and learning fosters psychological safety by normalising calculated risk-taking without fear of punishment for failure. Teams that treat mistakes as learning data rather than grounds for blame feel safe to speak up, challenge assumptions and propose untested ideas — directly satisfying the stem's requirement to identify practices that build psychological safety.

Admitting mistakes as a leader

A leader admitting mistakes models vulnerability, signalling that errors are learning data rather than punishable failures. This directly satisfies the psychological-safety requirement by lowering the interpersonal risk team members perceive when speaking up. It normalises fallibility across the team, so members disclose problems earlier instead of concealing them.

Improved team collaboration and satisfaction

An Agile mindset fosters shared ownership and open communication, directly improving team collaboration and satisfaction. This satisfies the stem's requirement for a benefit by addressing the human and social dimensions of delivery, rather than process artefacts or tooling. Cross-functional, self-organising teams report higher morale because they control their own work.

Faster delivery of value to the customer

Frequent, incremental releases let working software reach customers early, so value is realised sooner rather than at a single end-of-project handover. This directly satisfies the stem's benefit criterion by shortening the feedback loop, enabling course correction before investment compounds.

High level of transparency and honest communication

Transparency and honest communication let teams surface impediments, risks and bad news early, which is precisely the psychological-safety signal a healthy Agile culture depends on. Without it, status reporting becomes theatre and empirical inspection fails. This directly satisfies the stem's requirement for a cultural health indicator rather than a process artefact.

Team members feel comfortable sharing their mistakes

Psychological safety, where people openly admit errors without fear of blame, signals a healthy Agile culture because it enables inspect-and-adapt learning. Teams that hide mistakes cannot surface problems early, undermining the empirical transparency Agile depends on.

Valuing collaboration over individual silos

Valuing collaboration over individual silos reflects the Agile mindset's emphasis on cross-functional teamwork and collective ownership, directly satisfying the stem's requirement for a hallmark. Agile practise prioritises shared accountability and continuous communication over departmental isolation, enabling self-organising teams to deliver value iteratively rather than through handoffs between separate functions.

Adapting to change rather than fearing it

Adapting to change rather than fearing it reflects the Agile mindset's core principle of embracing evolving requirements, even late in development. This directly satisfies the stem's demand for a hallmark, distinguishing Agile's responsive stance from plan-driven methodologies that treat change as deviation to be controlled through rigid baseline management.

Learning through experimentation and empirical data

Learning through experimentation and empirical data reflects the Agile mindset's empirical pillar, satisfying the stem's demand for a hallmark. Rather than relying on predictive planning or upfront specification, this approach inspects real outcomes and adapts accordingly, which underpins iterative delivery and continuous improvement central to Agile practise.

Focus on removing impediments that stop the team from working

Servant leaders prioritise the team's ability to deliver by clearing blockers, so removing impediments that stop work directly satisfies the stem's requirement. This unblocking behaviour is the defining operational act of servant leadership, shielding the team and enabling flow rather than directing tasks.

Help the team become more self-organizing and mature

Servant leaders deliberately shift authority to the team, coaching members so they can make decisions and manage their own work without direction. Helping the team become more self-organising and mature satisfies the stem's requirement by describing this developmental, enabling behaviour rather than command-and-control leadership.

Action items for the next sprint.

Action items for the next sprint belong in the retrospective because the ceremony closes by converting identified improvements into owned, tracked commitments. This satisfies the stem's requirement for a typically discussed retrospective item, distinguishing it from sprint planning or daily standup content, where forward work is instead selected or coordinated.

What could be improved.

Retrospectives examine what went well, what did not, and what could be improved, so this option supplies the forward-looking improvement element. It satisfies the stem's requirement for a typically discussed retrospective topic, prompting the team to identify concrete process changes for the next sprint.

What went well.

Discussing what went well satisfies the retrospective's purpose of inspecting how the last sprint went regarding people, relationships, processes and tools. It is a standard retrospective topic, alongside what did not go well and what to improve. The stem asks which items are typically discussed, and this is one of them.

Value-based prioritization.

Value-based prioritisation ranks backlog items by delivered business value, ensuring limited agile capacity flows to the highest-return work first. This satisfies the alignment constraint by tying day-to-day iteration selection directly to organisational priorities rather than effort, seniority or technical preference.

Strategic business objectives.

Strategic business objectives give the delivery team a stable reference point, so each increment demonstrably advances the organisation's stated goals. This satisfies the alignment constraint by connecting team-level backlog decisions to enterprise strategy, preventing local optimisation that delivers no measurable organisational benefit.

Stakeholder feedback loops.

Stakeholder feedback loops provide the recurring mechanism for validating that work in progress still matches shifting organisational priorities. This satisfies the alignment constraint by enabling course correction between iterations, rather than confirming alignment once at project initiation when priorities may already have moved.

Encourage shared responsibility for outcomes rather than individual tasks.

Shared ownership of outcomes shifts focus from individual task completion to collective delivery, which is the mechanism that builds collaborative culture. Team members coordinate and help each other because success is measured jointly, satisfying the agile leader's goal of fostering collaboration.

Promote transparent communication and information sharing across the team.

Transparent communication and information sharing remove knowledge silos, giving every member visibility of progress, impediments and decisions. This openness is the mechanism enabling trust and joint problem-solving, directly satisfying the stem's requirement to foster a collaborative culture within the team.

Provide regular, transparent updates on progress and risks.

Regular, transparent updates on progress and risks build trust by keeping stakeholders informed before issues escalate, directly addressing the engagement gap. This satisfies the stem's requirement for a leadership method that improves stakeholder engagement through open, ongoing communication.

Invite stakeholders to participate in sprint reviews and planning meetings.

Inviting stakeholders to sprint reviews and planning meetings gives them direct visibility into increments and backlog decisions, converting passive recipients into active participants. This satisfies the stem's requirement for a leadership method that improves stakeholder engagement through genuine involvement.

It should be clear and concise.

A sprint goal must be clear and concise so every team member can state, without ambiguity, what the sprint intends to achieve and whether the selected backlog items serve it. That shared, memorable focus guides daily trade-off decisions and underpins meaningful inspection at the sprint review.

It should focus on the business value delivered.

Framing the sprint goal around business value keeps the team focused on the outcome the increment delivers rather than a list of tasks, satisfying the stem's demand for an essential element of an effective goal.