CCNA Agile Frameworks and Methodologies Questions

The Sprint Retrospective is the only Scrum event whose explicit purpose is inspecting how the team worked and adapting its process, satisfying the continuous-improvement constraint. Unlike the Daily Scrum, which inspects progress toward the Sprint Goal, it focuses on people, interactions, tools and Definition of Done, producing actionable improvements for the next Sprint.

Splitting an oversized story into smaller sprint-sized items lets the team deliver value within one Sprint while preserving the Product Owner's intent. This collaborative refinement satisfies the Sprint timebox constraint that the original story violates.

This is principle #3.

The Definition of Done is a shared commitment created by the Scrum Team, not imposed by one person. A workshop lets Developers, the Product Owner, and the Scrum Master agree on quality criteria that every Increment must meet. This creates transparency and a common standard, replacing individual interpretations and enabling consistent delivery of potentially releasable work.

The board reveals that work accumulates in 'In Progress' while 'Testing' is empty, indicating a bottleneck or handoff problem. Kanban emphasizes making work visible and managing flow. Analyzing the workflow to find why items are not moving to testing—such as missing test environments, unclear exit criteria, or insufficient testers—and then adjusting policies or capacity addresses the root cause and restores flow.

Scrum protects the Sprint from scope changes that would endanger the Sprint Goal. New requests are captured in the Product Backlog, where the Product Owner can order them against other items. The Developers then select work during the next Sprint Planning based on value and capacity, preserving the current Sprint's focus and the agreed Sprint Goal.

The Sprint Retrospective is a formal Scrum event held at the end of each Sprint, giving the team a dedicated opportunity to inspect its process and identify improvements, satisfying the framework's requirement for a recurring inspect-and-adapt ceremony.

This is one of the four values.

The Scrum Master should help the team inspect and adapt the Definition of Done if it does not ensure value. A shared understanding of quality and value is essential. Facilitating a conversation between the Product Owner and Developers can reveal gaps and lead to an improved Definition of Done that better supports delivering valuable increments.

In Scrum, the Sprint Backlog is owned by the Developers and can be updated as more is learned. Since the team believes the Sprint Goal remains achievable, adding the new feature is acceptable. The Sprint Goal provides focus but does not freeze the scope; the team self-manages its work to maximize value.

Fair rotation supports team collaboration.

Creating a high-level plan early and elaborating progressively satisfies the organisation's upfront planning mandate without abandoning agile delivery. This is rolling-wave planning: the plan exists from the outset, but detail is deferred until the last responsible moment, so Scrum's empirical, iterative cycles continue while the governance requirement for an initial documented plan is met.

Prioritising individuals and interactions over processes and tools is a core Agile Manifesto value shared across Scrum, XP and Kanban. It satisfies the question's requirement for a principle common to multiple methodologies, not one specific framework.

Scrum suits high uncertainty through short sprints, empirical inspection and adaptation, and a groomed backlog that absorbs changing requirements. This satisfies the uncertainty constraint by delivering increments frequently, letting the team learn and re-plan rather than committing to a fixed upfront scope.

Continuous integration shortens integration delays, a common hidden contributor to cycle time. This satisfies the stable-demand constraint: rather than adding capacity, the team removes the queueing and rework caused by deferred integration, so items flow through the board faster.

The Sprint Retrospective is the last event of the Sprint and occurs after the Sprint Review and before the next Sprint Planning. Holding it at this time allows the team to inspect the past Sprint and identify improvements before planning the next one. This sequencing is defined in Scrum and supports continuous improvement.

Capping WIP forces the team to finish work before starting more, which directly curbs multitasking and its context-switching overhead. This improves focus and shortens cycle time, satisfying Kanban's flow-efficiency constraint rather than merely tracking throughput.

Kanban boards render every work item and its stage on a shared visual surface, exposing bottlenecks, work-in-progress limits and queue build-up that hidden backlogs conceal. This directly satisfies the stem's requirement for a key benefit: making workflow state and flow constraints immediately visible to the whole team.

SAFe's programme increment planning synchronises multiple Scrum teams, exposing and resolving cross-team dependencies during a fixed planning cadence. This directly addresses the stem's inter-team dependency delays, providing the coordination layer that standalone Scrum lacks at scale.

The on-site customer practice in XP requires a real customer to be available full-time to the team. This person defines user stories, prioritizes them, and answers questions immediately. This continuous involvement ensures the team builds what the customer needs and receives rapid feedback, which is a core XP value.

Oversized user stories commonly cause carry-over because they hide complexity and resist completion within a Sprint. Helping the team slice stories smaller improves flow and forecasting before other interventions such as process changes are considered.

The board shows more cards in a column than that column's stated WIP limit permits, which is the violation the exhibit exposes. Exceeding the limit breaks the pull system's constraint, signalling the team must finish work before starting more.

The Sprint Goal gives the team focus and should not be changed arbitrarily. The Scrum Master should coach the Product Owner to refine and order new items for future Sprints, or if the new information invalidates the Sprint Goal, discuss whether the Sprint should be cancelled. This preserves empiricism and protects the team's focus.

The Daily Scrum is one of the five Scrum events defined in the Scrum Guide: a 15-minute daily inspection and adaptation by the Developers. This satisfies the stem's requirement to identify genuine Scrum events, distinguishing it from non-events such as backlog refinement.

Daily integration into a shared trunk forces small, frequent merges, directly eliminating the long-lived branch divergence causing conflicts and integration delays. This is the defining practice of continuous integration, and it addresses the stem's constraint of frequent merge conflicts.

Test-driven development is a core XP engineering practise: tests are written before production code, then code is refactored to pass them. This satisfies the stem's requirement for a characteristic XP practise, distinguishing XP's technical discipline from Scrum's process focus.

The Scrum Master is one of the three accountabilities defined in the Scrum Guide, serving the Scrum Team by coaching, removing impediments and fostering empiricism. This satisfies the stem's requirement for a formally defined Scrum role, alongside the Product Owner and Developers.

Velocity is an empirical measure, so planning against the observed 30 points replaces the optimistic 40-point estimate. This aligns sprint scope with demonstrated capacity, prevents overcommitment, and gives the Product Owner a realistic forecast without punishing the team for learning the technology.

Setting explicit pairing expectations and rotating driver/navigator roles addresses the discomfort by distributing control and reducing constant correction. The navigator reviews strategy rather than seizing the keyboard, so feedback becomes collaborative. Regular rotation satisfies the stem's need to foster a positive pairing experience within XP practice.

Scrum favors empirical, incremental improvement. By selecting only one or two actions and placing them in the Sprint Backlog, the team makes the improvement work visible alongside product work, and reviewing status at the next Retrospective closes the inspect-and-adapt loop. This is exactly how the Sprint Retrospective is meant to produce a tangible change rather than a wish list.

Sizing each story to fit within a single sprint keeps it independently deliverable and testable, satisfying the INVEST criterion of small size. This directly addresses the stem's best-practice requirement for well-formed stories, preventing stories that sprawl across iterations and stall feedback.

The Product Backlog is a formal Scrum artifact: an emergent, ordered list of everything needed to improve the product, owned by the Product Owner. It is the single source of work undertaken by the Scrum Team.

The root cause is that the product owner built user stories on assumptions without stakeholder validation. Coaching collaboration during the sprint lets assumptions be tested early, preventing costly rework and aligning delivered features with actual stakeholder needs before capacity is consumed.

A widening 'In Progress' band on a CFD indicates that more items are entering that stage than leaving it. This accumulation signals a bottleneck, where work is piling up because the stage cannot keep up with demand. The flat 'Done' band confirms that throughput is not increasing, so the team should investigate and address the constraint.

The Sprint Retrospective exists to inspect how the last Sprint went regarding individuals, interactions, processes, tools and Definition of Done, then adapt those elements. This directly satisfies the stem's focus on process improvement, distinguishing it from the Daily Scrum's daily inspection or the Sprint Review's product increment focus.

A Scrum Master must coach self-organisation, not direct work. Assigning tasks and tracking individuals sustains command-and-control, which demotivates the team. Coaching ownership satisfies the transition constraint by shifting authority to the team, letting them pull and manage their own work.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It must be shared and understood by the entire Scrum Team—Product Owner, Scrum Master, and Developers—so everyone agrees on what 'done' means. This shared understanding prevents disputes about completeness and ensures transparency.

The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. The Scrum Master should coach the team to self-manage the event, focus on the Sprint Goal, and avoid status reporting to the Scrum Master, which improves collaboration and keeps the event time-boxed.

The Sprint Review inspects the Increment, and only work meeting the Definition of Done is considered part of the Increment. The Scrum Master should guide the team to demonstrate completed items and use the review to inspect progress, adapt the Product Backlog, and gather stakeholder feedback, rather than presenting unfinished work as done.

Continuous integration requires developers to merge code into a shared repository frequently, with automated builds and tests detecting incompatibilities early. This directly resolves the distributed team's integration issues and delays caused by incompatible code changes, a specific XP practice addressing exactly that constraint.

Iterative delivery produces working increments each cycle, so stakeholder feedback and newly discovered requirements can be incorporated into subsequent iterations rather than frozen at project start. This directly satisfies the stem's demand for adaptation to changing requirements, which predictive waterfall planning cannot accommodate once baselined.

Having the team discuss the lateness and agree a new start time, with a commitment to punctuality, lets the team self-organise and own the solution. This satisfies the stem's constraint by addressing the behaviour collaboratively rather than imposing a manager's fix.

Backlog refinement is the ongoing process of reviewing and updating the Product Backlog, including breaking down large items into smaller, clearer ones. It gives the Product Owner and Developers a shared understanding of the story before Sprint Planning. This directly addresses unclear requirements and helps ensure the team can estimate and implement the story effectively.

Scope added mid-sprint inflates remaining work, breaking the burndown and risking the sprint goal. Renegotiating scope with the product owner restores a realistic forecast, either by removing equivalent planned work or deferring the new items to the next sprint.

The dependency cannot be resolved until the next sprint, so the definition of done is unattainable within the current goal. Facilitating product owner and team discussion to renegotiate the sprint goal addresses the impediment collaboratively, which is the Scrum Master's servant-leadership responsibility before escalation.

Kanban is a pull system: a new card may enter In Progress only when capacity frees up. Since the column sits at its WIP limit, the team must first complete an existing item and move it to Done, creating the slot.

Test-Driven Development (TDD) requires writing automated tests before writing the code. These tests form a safety net that verifies behavior remains correct during refactoring. In XP, TDD is a core practice that enables developers to improve design confidently. By running the tests after each change, the developer can detect regressions immediately and refactor safely.

New requests during Sprint Review are product backlog items, not scope for the current Sprint. The Product Owner alone orders and prioritises the backlog, so routing changes there preserves the Sprint's fixed goal while allowing stakeholders' input to be evaluated for future Sprints.

The Sprint Retrospective is the event where the team inspects how the last Sprint went with regard to individuals, interactions, processes, tools, and their Definition of Done. It is the only Scrum event specifically designed for the team to identify and address process improvements. Focusing here lets the team own follow-up actions on recurring concerns and adapt its way of working before the next Sprint begins.

Velocity is a planning constraint, not a target to exceed. The team and Product Owner renegotiate scope, removing lower-priority Product Backlog items so the Sprint Backlog fits historical capacity, preserving the Sprint Goal and sustainable pace.

Self-organising teams make decisions locally without waiting for managerial approval, so choices are reached faster. This satisfies the stem by naming a genuine benefit: authority to decide sits with those closest to the work, removing escalation delays and accelerating commitment to the chosen course.

The Product Owner owns the Product Backlog and prioritises items to maximise the value the Development Team delivers each Sprint. This accountability, rather than task assignment or process facilitation, is the role's defining purpose within Scrum.

Scrum allows the scope of a Sprint to be clarified and renegotiated between the Product Owner and the developers as more is learned, provided the Sprint Goal is not endangered. The developers own the Sprint Backlog and can adjust it. This response keeps the goal intact while responding to new value, which is exactly the flexibility Scrum intends.

Fifteen minutes is the fixed timebox for the Daily Scrum, regardless of team size, so it directly resolves the stem's overrun constraint. The event inspects progress toward the Sprint Goal and adapts the Sprint Backlog, with discussion deferred to follow-up conversations rather than extending the meeting.

The first Kanban practice is to visualize the workflow by mapping the actual steps work takes, from request to delivery. This value stream view exposes handoffs, queues, and delays. Without an accurate map of the real process, later practices like limiting work in progress or measuring flow cannot be applied meaningfully, because the team would be optimizing a fictional workflow.

Self-organisation develops through practise, not instruction. Prompting the team to reach decisions collaboratively, while the Scrum Master removes impediments rather than directing work, shifts ownership to the team and builds the capability to act without waiting for orders.

Kanban improves flow by making work and its constraints visible, and explicit WIP limits are the core mechanism for exposing bottlenecks. Limiting the Code Review column forces the team to stop starting new work there and instead swarm to finish reviews, revealing whether reviewers are the constraint. Making aging items visible adds the data needed to inspect and adapt the policy later.

Mid-sprint scope changes break the sprint goal and cause the 40% incompletion. Facilitating stakeholder negotiation protects the sprint backlog, letting the team deliver its committed increment and restoring predictable velocity, directly addressing the overcommitment caused by the Product Owner accepting urgent requests under pressure.

Continuous integration in XP means integrating and testing code many times a day, typically with every commit. This practice reduces integration problems and provides rapid feedback. Nightly builds are not frequent enough to catch issues early, which is a core XP value.

A stable velocity of 30 story points means 50 is unachievable without sacrificing quality or predictability. Coaching the Product Owner to reduce scope or extend the deadline respects the team's empirical capacity rather than imposing an arbitrary target.

Historical velocity gives the team an empirical basis for forecasting capacity, directly addressing the overcommitment pattern. Coaching them to select only what past Sprints prove deliverable satisfies the stem's constraint of consistent failure to complete committed items, without the Scrum Master imposing the commitment.

Start-Stop-Continue provides a balanced framework that encourages the team to identify what to start doing, stop doing, and continue doing. This structure helps the team generate actionable improvements and prevents the meeting from becoming purely negative. It is a common agile retrospective technique.

The Sprint Review is meant to be a collaborative working session, not a demo. The Scrum Master should coach participants to inspect the Increment, elicit stakeholder feedback, and adapt the Product Backlog together. This shifts the event from a one-way presentation to a genuine feedback loop, restoring its value and aligning future work with stakeholder needs.

Prioritising items is a core refinement activity: the Product Owner reorders the backlog so the most valuable, ready items sit at the top, keeping the team focused on what delivers value next. This satisfies the stem's requirement for a genuine refinement activity rather than a Sprint Planning or Review task.

The Sprint Review is a Scrum event held at the end of each Sprint, where the Increment is inspected and stakeholders give feedback. It is one of Scrum's five formal ceremonies, satisfying the framework-practice constraint.

Smaller work items reduce variance in cycle time, since each item spends less time queued and in progress, making completion dates more predictable. This directly addresses the team's predictability goal without altering throughput or capacity, and aligns with Kanban's core guidance on sizing cards to smooth flow.

The Scrum Master protects the Sprint Goal by coaching the Product Owner that scope changes endangering it must wait until the next Sprint. This upholds the Sprint's fixed scope, addressing the frequent mid-Sprint additions disrupting the team.

The Sprint Backlog emerges from Sprint Planning, where the team selects Product Backlog items and defines how to deliver them. It is therefore created during that event, not before it, and is owned solely by the Developers.

Sprint Planning is one of the five formal Scrum events defined in the Scrum Guide, alongside the Daily Scrum, Sprint Review, Sprint Retrospective and the Sprint itself. It is a timeboxed ceremony where the team agrees the Sprint Goal and selects backlog items, satisfying the question's requirement for a defined Scrum ceremony.

Remaining capacity is the difference between the team's established velocity and the points already committed. Subtracting the 22 committed points from the 30-point velocity leaves 8 points of capacity available for additional work in this sprint.

Scrum directly satisfies the stem's three constraints: iterative development through fixed-length Sprints, time-boxed ceremonies such as the Daily Scrum and Sprint Review, and a Product Backlog ordered by the Product Owner. Its defined roles and artefacts give an Agile-inexperienced team the structural scaffolding they currently lack.

Defining process policies makes workflow rules explicit, satisfying Kanban's requirement that work states and transition criteria be visible. Policies specify entry and exit conditions for each column, limiting work in progress and standardising handoffs. This transparency enables the team to identify bottlenecks and improve flow systematically.

Choosing Product Backlog items for the Sprint is the first Sprint Planning activity, where the team forecasts what it can deliver. This satisfies the meeting's purpose of deciding the Sprint's scope, drawing on refined backlog items and the team's historical velocity.

A small, complete user story produces a genuinely finished increment, exercising the full definition of done while the team forms and learns the codebase. This satisfies the product owner's need for a visible outcome without overcommitting during the first sprint's inevitable learning curve.