Agile Project Management

Agile Project Management - Practice Questions

3 sections · About 43 minutes to read

Version 1.0 · 4 November 2026

100 original study questions based on Robert Clines’s October 21, 26, 28 and November 2 sessions and the supplied version 8.0 workbook. These are editorial practice, not actual exam questions or an official exam blueprint. Course-specific conventions are labeled. Calculations use the assumptions in each prompt.

Use the Complete Guide, Quick Review and Source Index after your first attempt. Workbook citations use PDF-viewer page numbers, counting the cover as page 1. In the web version, answers save in this browser under this course’s own page.

Questions

A. Approach and feedback

  1. An app’s users are unsure which interface will help them. What makes an adaptive approach worth considering?

    • A. Small usable slices can generate feedback that shapes later work.
    • B. The team can stop doing requirements work.
    • C. The entire scope must be fixed before any feedback.
    • D. The approach guarantees a shorter total project.
  2. A known physical installation has tightly coupled steps and costly rework. What should guide the approach choice?

    • A. Choose Agile because every modern project should use it.
    • B. Choose solely from the team’s preferred job titles.
    • C. Assume predictive work cannot incorporate feedback.
    • D. The stability of the result, dependencies, constraints and opportunities for feedback.
  3. What is the main difference between iterative and incremental work?

    • A. Iterative work forbids releases; incremental work forbids feedback.
    • B. They describe identical concepts in every situation.
    • C. Iterative work improves a solution through feedback; incremental work adds usable completed portions.
    • D. Iterative work uses hours; incremental work uses dollars.
  4. A team tests a rough prototype with users. What can it conclude?

    • A. The team must count the prototype as a deployed release.
    • B. The feedback can inform the solution, but the prototype is not automatically a production-ready increment.
    • C. The prototype proves all acceptance criteria are met.
    • D. No more stakeholder conversations are needed.
  5. A product has a hard six-week deadline. What does that establish about Agile suitability?

    • A. The team must examine feasible scope, resources, risks and dependencies; the date alone does not decide.
    • B. Agile is categorically prohibited.
    • C. All requested scope can fit because sprints are short.
    • D. Estimates are unnecessary when the finish date is fixed.
  6. What is rolling-wave planning?

    • A. Commit every detail for the full project before learning begins.
    • B. Avoid planning until the product is already released.
    • C. Reassign every unfinished story to the next sprint automatically.
    • D. Plan near work in greater detail and revisit later work as knowledge improves.
  7. What does working software over comprehensive documentation mean in the course?

    • A. Complete all possible documents before demonstrating functionality.
    • B. Documentation determines whether customer feedback is allowed.
    • C. Emphasize working value while producing necessary documentation.
    • D. Never document anything.
  8. Which arrangement describes DSDM as taught?

    • A. Only documentation is allowed to change.
    • B. Cost and schedule stay fixed while scope can flex.
    • C. Scope, time and cost all expand without review.
    • D. Scope is fixed and both cost and schedule are unlimited.
  9. Which practice is central to the course’s Kanban description?

    • A. Prioritize work and limit work in progress to improve flow.
    • B. Begin every candidate immediately.
    • C. Measure progress only by the number of meetings.
    • D. Replace all business needs with feature names.
  10. A program combines iterative app development with a predictive infrastructure cutover. How should this be understood?

    • A. The teams no longer need a shared dependency view.
    • B. The program must force every component into identical cycles.
    • C. Having any predictive component prevents iterative delivery elsewhere.
    • D. A deliberate combination can fit different work while dependencies are coordinated.

B. Roles and decision boundaries

  1. Who orders the product backlog on behalf of business value in the course?

    • A. The Scrum Master acting as the task boss.
    • B. The highest-paid available specialist regardless of role.
    • C. The Product Owner working with the business.
    • D. A rotating individual developer acting alone.
  2. Who determines the feasible amount of work to select for a sprint?

    • A. The previous sprint’s number, treated as an unchangeable quota.
    • B. The team, using estimates, availability and dependencies.
    • C. The PO alone, regardless of team estimates.
    • D. A stakeholder who requests the most work.
  3. A Product Owner is not a business analyst. What follows?

    • A. That can be appropriate if the person can perform the role and make the needed business decisions.
    • B. The person is automatically disqualified.
    • C. The Scrum Master must take over every priority decision.
    • D. The team must stop eliciting requirements.
  4. What best describes the Scrum Master in this course?

    • A. A manager who assigns every implementation action.
    • B. A substitute for all stakeholder decisions.
    • C. An observer prohibited from helping with outside obstacles.
    • D. A coach/facilitator who helps remove impediments and protect focus.
  5. A team member finishes their task and waits, despite another deliverable needing help. What should self-management encourage?

    • A. Start the lowest-priority feature without discussion.
    • B. Ignore the remaining work because it has another person’s name.
    • C. Discuss useful next work and help the team deliver within skills and access boundaries.
    • D. Wait indefinitely for a manager to assign every action.
  6. A resource manager directly orders a fully allocated team to abandon sprint work. What is the best response?

    • A. Let every member choose a conflicting response individually.
    • B. Clarify urgency and route the priority discussion through SM/PO and the agreed process.
    • C. Silently change work without notifying anyone.
    • D. Refuse to hear any business need.
  7. A PO has no authority to settle competing business priorities. What is the key concern?

    • A. The team lacks an effective route for timely product decisions.
    • B. A different estimation-card color is needed.
    • C. The team must accept every story as equally first.
    • D. Only the team’s technical skill determines product priority.
  8. Cross-functionality is best understood as what?

    • A. Every person has every technical permission and expertise.
    • B. Team members must never work outside a narrow title.
    • C. Any external dependency can be ignored.
    • D. The team can cover needed delivery work collaboratively and coordinate specialists where needed.
  9. What is the instructor’s preferred team-size convention?

    • A. At least twelve people in every sprint.
    • B. No limit or communication consideration should be discussed.
    • C. Nine or fewer team members if possible, treated as a course recommendation.
    • D. Exactly nine people for every team in every framework.
  10. Where an external project manager is used alongside an Agile team, what work can that role coordinate?

    • A. Prove that the project has no organizational governance.
    • B. Budgets, approvals, reporting, dependencies and release obligations.
    • C. Eliminate the team’s capacity decisions.
    • D. Replace every Product Owner decision.

C. Requirements and elicitation

  1. Why is simply recording initial user wishes often insufficient?

    • A. Users and builders may need continuing collaboration to discover and clarify actual needs.
    • B. Users can never provide useful information.
    • C. Technical staff should design without consulting stakeholders.
    • D. A signed request guarantees complete shared understanding.
  2. Which set contains the four top-level requirement categories used in the course?

    • A. Business, functional, non-functional and cost.
    • B. Scope, schedule, budget and quality.
    • C. Card, conversation, confirmation and estimate.
    • D. Business, stakeholder, solution and transition.
  3. “Increase repeat-customer engagement” most directly expresses which requirement category?

    • A. Functional solution.
    • B. Sprint task.
    • C. Business.
    • D. Transition.
  4. “Customer-service staff need to see a caller’s recent contacts” most directly expresses what?

    • A. A project budget baseline.
    • B. A stakeholder-group need.
    • C. A temporary migration requirement.
    • D. A story-point scale.
  5. “Allow an authorized student to submit a practice answer” is primarily what?

    • A. A functional solution capability.
    • B. A transition-only requirement.
    • C. A velocity measure.
    • D. A business-case funding decision.
  6. “Return the result within two seconds under a defined load” is primarily what?

    • A. An epic because it contains a number.
    • B. A temporary training requirement.
    • C. A daily meeting agenda.
    • D. A non-functional performance condition.
  7. Which is the clearest transition requirement?

    • A. Run the daily collaboration meeting.
    • B. Assign eight story points to a candidate.
    • C. Migrate existing records and train users before retiring the old system.
    • D. Permanently display current account balances.
  8. An application automatically logs out an inactive user. Does the word “out” make it a transition requirement?

    • A. No; security can never be described in requirements.
    • B. No; classify the ongoing product behavior/quality statement, not the ordinary meaning of changing state.
    • C. Yes; every screen-state change is a transition requirement.
    • D. Yes; all security-related work is migration.
  9. Which technique can support elicitation?

    • A. Interview users and check the interpretation with them.
    • B. Treat the first feature list as unquestionably complete.
    • C. Copy an estimate and stop asking questions.
    • D. Use a release date as a substitute for requirements.
  10. How should a need and a requirement relate?

    • A. A need is always a technical design instruction.
    • B. Every requested feature proves its own business value.
    • C. Requirements describe only cost and never behavior.
    • D. The requirement provides a usable capability/condition that addresses the underlying need.

D. Epics, stories and confirmation

  1. “As a customer, I want to manage all my finances” is best treated how?

    • A. As a complete acceptance test.
    • B. As evidence that business priorities are unnecessary.
    • C. As broad work to clarify and decompose into smaller valuable stories.
    • D. As one fully specified task ready to code.
  2. A small story cannot be estimated because an API behavior is unknown. What is the best conclusion?

    • A. Remove all acceptance criteria to make it smaller.
    • B. Investigate and clarify the uncertainty; lack of an estimate alone does not prove the story is a large epic.
    • C. It must be a huge epic regardless of scope.
    • D. Assign the largest card automatically.
  3. Which story most clearly identifies user, capability and benefit?

    • A. As a student, I want to filter questions by module so I can focus revision on a weak subject.
    • B. Build a new database table and a button.
    • C. Improve everything immediately.
    • D. The system shall use a fashionable framework.
  4. What are the three Cs?

    • A. Cost, control, contract.
    • B. Complexity, cadence, capacity.
    • C. Charter, code, close.
    • D. Card, conversation, confirmation.
  5. What is a user story’s primary purpose in the supplied course?

    • A. Guarantee delivery of every requested feature.
    • B. Replace all testing and quality work.
    • C. Communicate user value and prompt analysis/conversation.
    • D. Contain every implementation detail with no further discussion.
  6. Which is the strongest acceptance criterion for the module-filter story?

    • A. The code uses a particular folder name even though no constraint requires it.
    • B. Selecting Module 5 displays only questions tagged to that module.
    • C. The filter is nice.
    • D. The team thinks it looks finished.
  7. Why ask which credit cards are valid in a payment story?

    • A. Conversation exposes rules that a short story did not specify.
    • B. It proves the story should never be discussed.
    • C. It removes the need for negative test cases.
    • D. It transfers every priority decision to the payment library.
  8. A team completes every database table but no usable screen or service. What should it examine?

    • A. Whether infrastructure work is always forbidden.
    • B. Whether story points can substitute for working functionality.
    • C. Whether all testing can be postponed indefinitely.
    • D. Whether work can be sliced across needed layers to deliver a useful capability.
  9. Why consider several user roles rather than a single generic user?

    • A. It eliminates stakeholder conversations.
    • B. It makes acceptance criteria unnecessary.
    • C. Different goals, frequency and proficiency can reveal different requirements.
    • D. It guarantees that all roles need identical behavior.
  10. Acceptance criteria emerge as a story is clarified. What should the team do?

    • A. Equate every criterion with a mandatory code design.
    • B. Update shared understanding and testing expectations as information improves.
    • C. Treat the first wording as permanently complete.
    • D. Assume any new detail must be hidden from the PO.

E. Planning and activity purposes

  1. Which sequence lists the five planning levels taught?

    • A. Vision, roadmap, release, sprint, daily.
    • B. Charter, contract, invoice, audit, closure.
    • C. Card, conversation, confirmation, code, cost.
    • D. Planning, design, build, test, support only.
  2. What is the main purpose of a roadmap?

    • A. Record only yesterday’s completed hours.
    • B. Replace the Definition of Done.
    • C. Assign every task for every future sprint permanently.
    • D. Describe strategic rollout direction for the product/capabilities.
  3. What should release planning produce in the course?

    • A. Permission to ignore the next sprint’s capacity.
    • B. A retrospective about only the previous day.
    • C. A forecast of candidate stories across upcoming sprints, with priorities and relative estimates.
    • D. An irreversible guarantee of each future sprint’s contents.
  4. What happens during sprint planning?

    • A. Every item in the product backlog becomes a commitment.
    • B. The PO clarifies candidate work and the team selects/plans a feasible amount.
    • C. Stakeholders perform the sprint review before anything is built.
    • D. Only the Scrum Master chooses estimates and tasks.
  5. Why use backlog refinement/story time?

    • A. Clarify upcoming stories, questions and dependencies before later selection.
    • B. Automatically commit all discussed items to the next sprint.
    • C. Hide unclear requirements until the final demonstration.
    • D. Replace all release and sprint planning.
  6. What are the daily stand-up’s three prompts in the course format?

    • A. Budget approval, vendor selection and annual bonuses.
    • B. Only the Scrum Master’s personal task list.
    • C. A detailed design review of every future feature.
    • D. Work since the last meeting, intended next work and impediments.
  7. A detailed design debate begins during the stand-up. What should happen?

    • A. Prohibit the problem from ever being discussed.
    • B. Hide it until the end of the project.
    • C. Record the issue and arrange appropriate follow-up after the brief meeting.
    • D. Let the debate consume the entire morning by default.
  8. Who participates in the course’s sprint review, and for what?

    • A. Only future customers to estimate all backlog tasks.
    • B. The team, PO and relevant stakeholders inspect/demonstrate completed work and exchange feedback.
    • C. Only auditors to finalize annual budgets.
    • D. Only the SM to evaluate personal salaries.
  9. What is the central purpose of a sprint retrospective?

    • A. Improve the way the team works and preserve useful practices.
    • B. Demo only the newest screen to customers.
    • C. Assign blame for every unfinished task.
    • D. Rank all future business investments.
  10. Which sprint duration is explicitly taught and clarified by the November 2 recording?

    • A. Exactly six weeks in every Scrum project.
    • B. No defined duration or cadence matters.
    • C. A mandatory one-day sprint.
    • D. One to four weeks, with two to three weeks an instructor preference.

F. Backlogs, boards and burndown

  1. How do the product backlog and sprint backlog differ?

    • A. The sprint backlog contains only work completed last year.
    • B. The product backlog is a record of daily attendance.
    • C. The product backlog holds ordered potential work; the sprint backlog concerns current selected work and its execution.
    • D. They always contain exactly the same items.
  2. A story is unfinished at sprint end. What happens in the course workflow?

    • A. It counts as completed if the developer was busy.
    • B. It returns to the product backlog for PO reprioritization.
    • C. It automatically goes first in the next sprint.
    • D. Its previous effort forces the business to finish it before anything else.
  3. A stakeholder requests an urgent feature during the sprint. What is the best first approach?

    • A. Clarify urgency/value and discuss it through the PO and agreed change process.
    • B. Silently add it and keep all capacity assumptions unchanged.
    • C. Allow the stakeholder to bypass all coordination.
    • D. Automatically cancel every sprint that receives a request.
  4. Who can terminate a sprint in the course’s exceptional termination scenario?

    • A. Any stakeholder independently.
    • B. Any team member without discussion.
    • C. The task-board software automatically whenever work is late.
    • D. The Product Owner.
  5. Which columns are commonly shown on the course task board?

    • A. Only estimated and unestimated.
    • B. Archived, deleted, never discuss.
    • C. To do, in progress, done.
    • D. Vision, roadmap, invoice.
  6. What does the course’s sprint burndown chart plot?

    • A. Only the original planned budget, without updates.
    • B. Remaining work in hours against sprint days.
    • C. Total salary against employee age.
    • D. Story count against number of meetings only.
  7. An editorial sprint starts with 80 remaining hours across 10 workdays. With a straight ideal line, how many hours should remain at the end of day 4?

    • Enter: Ideal remaining hours.
  8. In that same example, actual remaining work at the end of day 4 is 64 hours and ideal remaining work is 48. How many hours above ideal is the actual line?

    • Enter: Hours above ideal.
  9. A burndown stays above its ideal line. What can the chart alone establish?

    • A. The product is certain to be released on time.
    • B. Every requirement must be removed.
    • C. Remaining-work progress warrants investigation; the specific cause still needs evidence.
    • D. One named developer is definitely underperforming.
  10. What should be understood before interpreting the course’s 8/80 sizing guideline?

    • A. It automatically determines all dependency links.
    • B. It is a planning aid with exceptions, and decomposition is separate from sequencing.
    • C. It universally prohibits every task under eight hours.
    • D. It means every eight-point story takes eighty hours.

G. Estimation and prioritization

  1. New evidence contradicts an early estimate. What should a PM do?

    • A. Revise the forecast and explain changed assumptions and uncertainty.
    • B. Keep the old number solely because leaders remember it.
    • C. Claim the early estimate was a guarantee.
    • D. Remove the evidence from the record.
  2. How does the course distinguish cost and budget?

    • A. Cost is always points and budget is always defects.
    • B. They describe only the team’s meeting duration.
    • C. Budget is unrelated to when money is expected to be spent.
    • D. Cost is money charged/paid; budget allocates the estimate against scheduled work and time.
  3. Does splitting a rough top-down estimate across many tasks independently improve its accuracy?

    • A. Yes; every allocated number becomes a contractual guarantee.
    • B. Only if task names are written in capital letters.
    • C. No; the detail of the allocation does not add new estimating evidence.
    • D. Yes; more rows guarantee a precise estimate.
  4. Which statement accurately reports the preliminary-estimate source difference?

    • A. The lecture contains no estimate discussion.
    • B. The workbook allows top-down or bottom-up; the October 28 lecture groups it with bottom-up.
    • C. Both sources prohibit bottom-up preliminary estimates.
    • D. The workbook states all ranges are universal PMI rules.
  5. What does a story-point estimate represent?

    • A. Relative story size within the team’s estimating context.
    • B. A fixed number of hours valid for every team.
    • C. The order in which the PO must prioritize the story.
    • D. The percentage of annual budget already approved.
  6. A five-point story on Team A and a five-point story on Team B exist. What can be inferred directly?

    • A. They must take the same elapsed time.
    • B. The teams have identical skills and capacity.
    • C. Both stories must be selected first.
    • D. Neither equal hours nor equal productivity follows from those point values alone.
  7. Why reveal Planning Poker estimates simultaneously?

    • A. To make the highest-ranking person’s choice automatically win.
    • B. To turn story points into exact hours.
    • C. To preserve independent judgments and reduce anchoring/groupthink.
    • D. To eliminate the need to discuss the story.
  8. Planning Poker values differ widely. What is the best response?

    • A. Discard testing obligations until values match.
    • B. Discuss outliers and assumptions, clarify the work and estimate again.
    • C. Force everyone to copy the senior estimator immediately.
    • D. Take the mean and prohibit explanation.
  9. What priority order is presented in the course?

    • A. Business value, risk, difficulty, size.
    • B. Size alone, followed by alphabetical order.
    • C. Developer preference, meeting duration, cost-code length, color.
    • D. Every story has identical first priority.
  10. Why does the course also estimate tasks in hours?

    • A. A point universally equals one hour.
    • B. Hours eliminate all estimating uncertainty.
    • C. Only hourly estimates can identify business value.
    • D. Hours support task planning, organizational reporting and the taught burndown.

H. Velocity and realistic capacity

  1. An editorial sprint completes stories worth 3, 5 and 8 points. A 13-point story is 90% finished. What is velocity?

    • Enter: Completed story points.
  2. Why exclude a partly completed story from course velocity?

    • A. Incomplete stories can never be selected again.
    • B. Velocity counts stories meeting the agreed completion standard.
    • C. The effort never happened.
    • D. The PO must delete every unfinished item.
  3. An editorial team’s last three comparable velocities are 16, 20 and 18 points. What is the arithmetic mean?

    • Enter: Average points per sprint.
  4. With 54 comparable points remaining and a stable average velocity of 18 points per sprint, approximately how many sprints are forecast?

    • Enter: Forecast sprints.
  5. What should a forecast based on average velocity communicate?

    • A. That every future sprint must exactly match the mean.
    • B. That points from any other team can be substituted directly.
    • C. Its assumptions and uncertainty, including scope and team availability changes.
    • D. An unconditional completion guarantee.
  6. What is a calibration sprint in this workbook?

    • A. A way to guarantee the first velocity estimate is accurate.
    • B. A learning dry run with real work, excluded from the case’s formal metrics.
    • C. A mandatory additional formal Scrum event for every project.
    • D. A release that requires no testing.
  7. In an editorial capacity exercise, three people each have 10 days × 6 project hours. Two are fully allocated and one is 50% allocated. What is available capacity before reserves?

    • Enter: Available project hours.
  8. From 150 available project hours, an editorial team reserves 24 hours for production support. How many hours remain before other known obligations?

    • Enter: Remaining planning hours.
  9. Production support exceeds its planned reserve and a story remains unfinished. What should happen?

    • A. Hide the support work to preserve the original forecast.
    • B. Automatically add the remainder above all other business priorities.
    • C. Make the capacity impact visible and return unfinished work for PO reprioritization.
    • D. Award full velocity because the team was busy.
  10. Support demand is lower than the reserved capacity and useful time remains. What can the team consider?

    • A. Rewriting past velocity to match the plan.
    • B. Discussing a suitable additional candidate with the PO after checking capacity and readiness.
    • C. Starting any unrelated task without coordination.
    • D. Declaring that all future support reserves are unnecessary.

I. Execution, quality and integration

  1. A developer says a story is done because unit tests pass, but required integration work remains. What is missing?

    • A. A shared completion standard covering all required quality/readiness work.
    • B. A higher point estimate automatically fixes it.
    • C. The team must never use unit tests.
    • D. A successful stand-up proves release readiness.
  2. How do acceptance criteria and Definition of Done differ in this guide?

    • A. Criteria replace all quality checks.
    • B. Done means only the developer stopped typing.
    • C. They remove the need to talk to stakeholders.
    • D. Criteria confirm the particular story’s behavior; Done is the shared completion standard.
  3. Required tests, approvals and packaging are complete, but the authorized deployment window is next week. What distinction matters?

    • A. The deployment window makes all tests unnecessary.
    • B. Every sprint and release must be the same event.
    • C. Production-ready work can await actual deployment.
    • D. Ready work must always be live immediately.
  4. Stakeholders first see a story at the final review and reject a misunderstood behavior. What would reduce this risk?

    • A. Increase the point value after rejection to count it as complete.
    • B. Collaborate and show work during the sprint while clarifying acceptance.
    • C. Avoid stakeholders until all coding ends.
    • D. Use the review only to blame the requester.
  5. A review failed because of missing testing. What should a retrospective focus on?

    • A. Causes, a better completion/testing process and agreed actions, while avoiding blame.
    • B. Only identifying a person to punish.
    • C. Declaring every Agile method invalid.
    • D. Hiding the failure from future planning.
  6. An external team misses a dependency needed for a sprint story. What is the useful response?

    • A. Assume Agile eliminates outside dependencies.
    • B. Count the blocked story as completed anyway.
    • C. Directly change another team’s priorities without discussion.
    • D. Surface and coordinate the dependency, reforecast, and handle unfinished work through reprioritization.
  7. The organization requires regular budget reporting. What follows for an Agile project?

    • A. The organization may never request financial information.
    • B. All reporting must be copied unchanged even when an approved adaptation is possible.
    • C. Coordinate the required information and approvals with organizational governance.
    • D. Using sprints automatically exempts the project.
  8. What is Scrum of Scrums used to illustrate in the workbook?

    • A. A replacement for every team’s own work planning.
    • B. Representatives coordinating dependencies and integration between Scrum teams.
    • C. An individual’s salary review.
    • D. A ban on mixed predictive/adaptive programs.
  9. The workbook proposes a hardening sprint. What should be made explicit?

    • A. Its release/documentation effort and capacity, without hiding required unfinished quality work behind a done label.
    • B. That all earlier testing was optional.
    • C. That every Scrum project universally requires this practice.
    • D. That extra work consumes no team availability.
  10. A team has access to an occasional specialist only through another department. What should it do?

    • A. Treat cross-functionality as permission to bypass access controls.
    • B. Ignore the specialist work until the final review.
    • C. Add a specialist permanently regardless of need or cost.
    • D. Coordinate the expertise, permissions and timing rather than assuming it can do the work unaided.

J. Organization, myths and improvement

  1. Which statement about Agile documentation is supported?

    • A. Only documents matter; working results are secondary.
    • B. Documentation is prohibited if a team is distributed.
    • C. Useful and necessary documentation still needs to be produced.
    • D. Agile means zero documentation under every condition.
  2. Which statement about Waterfall and change is supported?

    • A. Agile is the only setting in which feedback exists.
    • B. It can handle change through an established process, though rework and coordination can be costly.
    • C. No predictive project can ever change.
    • D. Every change is free if it has an approval number.
  3. Does earlier incremental delivery prove every Agile project finishes sooner overall?

    • A. No; total duration depends on scope, conditions and how the work is delivered.
    • B. Yes; shorter sprints mathematically guarantee shorter projects.
    • C. No; all projects must take exactly one year.
    • D. Yes; organizational approvals stop applying.
  4. Can Agile teams be distributed?

    • A. No, the word Agile prohibits remote participants.
    • B. Yes, and therefore no working agreements are needed.
    • C. Only if all feedback is replaced by status documents.
    • D. Yes, with deliberate communication and collaboration practices.
  5. Why should the team help create ground rules?

    • A. Rules eliminate the need for coaching.
    • B. Only managers can identify useful collaboration habits.
    • C. Participation builds shared understanding and ownership of the working agreement.
    • D. Ground rules should never change after day one.
  6. A team is assigned to several projects in tiny daily fragments. What is a useful improvement?

    • A. Convert allocation percentages directly into story points.
    • B. Negotiate realistic allocation and more concentrated blocks of work where feasible.
    • C. Assume every person is fully available because their name is on the team.
    • D. Ban all organizational discussion of shared resources.
  7. Which set captures the course’s improvement targets?

    • A. Useful shorter cycles, smaller effective teams, dedication, collaboration, ground rules, management education and coaching.
    • B. More simultaneous work, no tests and no business decisions.
    • C. Always halve team size regardless of skills.
    • D. Always remove every formal approval without agreement.
  8. Why does management education matter during Agile adoption?

    • A. A slogan guarantees the organization will deliver faster.
    • B. Managers must stop receiving all business information.
    • C. Training the team makes leadership understanding irrelevant.
    • D. Support must include realistic expectations and respect for the new decision boundaries.
  9. What does fail fast mean in the course?

    • A. Repeat the same failure while changing its name.
    • B. Treat experimentation as permission to avoid accountability.
    • C. Recognize failure, learn from it and apply the lesson promptly.
    • D. Ignore required quality work to release anything quickly.
  10. What should a student take from the November 2 study discussion?

    • A. The instructor promised an exact current exam blueprint.
    • B. Prioritize Modules 3-5, roles, ceremony purposes/participants and sprint structure, while recognizing the exam recollection was tentative.
    • C. The practice bank contains actual current certification questions.
    • D. Historical dates are guaranteed to dominate the exam.

Explained answer key

A. Approach and feedback

1. Small usable slices can generate feedback that shapes later work. The advantage is learning and adaptation through useful increments. It does not eliminate requirements or guarantee a universal speed improvement. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

2. The stability of the result, dependencies, constraints and opportunities for feedback. The course emphasizes fit to the work. The scenario suggests examining predictive coordination, while still planning feedback and change. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

3. Iterative work improves a solution through feedback; incremental work adds usable completed portions. They can occur together. Learning from a prototype is iterative; adding a working capability is incremental. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

4. The feedback can inform the solution, but the prototype is not automatically a production-ready increment. Learning and readiness are different. Required quality and acceptance checks still apply. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

5. The team must examine feasible scope, resources, risks and dependencies; the date alone does not decide. Although the course uses fixed-date predictive examples, the lecturer also explicitly allows Agile projects with hard end dates. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

6. Plan near work in greater detail and revisit later work as knowledge improves. Progressive detail helps manage uncertainty while retaining a forward view. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

7. Emphasize working value while producing necessary documentation. The preference does not make the right-hand value worthless. Support and governance needs still matter. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

8. Cost and schedule stay fixed while scope can flex. The course describes constrained timeboxing: select work that fits the available time and money. (Oct 21, 00:24:58-00:53:19; segments 133-198.) (Oct 21, 00:54:28-01:02:00; segments 203-223.) (Workbook, PDF pp. 17-25.)

9. Prioritize work and limit work in progress to improve flow. WIP limits and priority help expose and manage flow. A board alone does not accomplish this. (Oct 21, 01:02:34-01:04:29; segments 225-229.) (Workbook, PDF p. 24.)

10. A deliberate combination can fit different work while dependencies are coordinated. The course gives mixed-program examples. Integration remains a program responsibility. (Oct 26, 02:26:11-02:27:40; segments 403-405.) (Workbook, PDF pp. 89-90.)

B. Roles and decision boundaries

11. The Product Owner working with the business. The PO coordinates needs and priorities. Team capacity is a different decision. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

12. The team, using estimates, availability and dependencies. The course distinguishes product priority from the team’s assessment of feasible work. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

13. That can be appropriate if the person can perform the role and make the needed business decisions. Clines explicitly says the PO need not be a BA. BA skills may be useful without making the job title compulsory. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

14. A coach/facilitator who helps remove impediments and protect focus. The role supports the process and team rather than issuing routine task orders. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

15. Discuss useful next work and help the team deliver within skills and access boundaries. Self-management includes organizing work and collaborating. It does not permit arbitrary priorities or unauthorized specialist actions. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

16. Clarify urgency and route the priority discussion through SM/PO and the agreed process. Protect the sprint’s focus while making urgency and tradeoffs visible. Shared-resource authority may require additional organizational negotiation. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

17. The team lacks an effective route for timely product decisions. Decision authority and stakeholder alignment matter; a title alone does not resolve conflicts. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

18. The team can cover needed delivery work collaboratively and coordinate specialists where needed. The course encourages broader contribution while recognizing scarce expertise and organizational access needs. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

19. Nine or fewer team members if possible, treated as a course recommendation. The supplied sources vary in wording. The guide retains the lecturer’s preference without presenting it as a universal current Scrum standard. (Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Nov 2, 00:26:44-00:30:20; segments 79-90.) (Workbook, PDF pp. 27-29.)

20. Budgets, approvals, reporting, dependencies and release obligations. The course describes this as an organizational integration arrangement, not a mandatory additional Scrum role. (Oct 26, 02:20:46-02:22:15; segments 391-394.) (Workbook, PDF pp. 87-88.)

C. Requirements and elicitation

21. Users and builders may need continuing collaboration to discover and clarify actual needs. Elicitation involves questions, interpretation checks and feedback rather than assuming everything is visible at the start. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

22. Business, stakeholder, solution and transition. Functional and non-functional are subdivisions of solution requirements, not extra top-level categories. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

23. Business. It states an organizational outcome. Further requirements must make the desired capabilities and measures concrete. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

24. A stakeholder-group need. The statement identifies the needs of a particular group. It can later be translated into detailed solution behavior. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

25. A functional solution capability. It describes behavior of the solution. Separate quality and access conditions may also need specification. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

26. A non-functional performance condition. The condition specifies how well the solution must perform under stated circumstances. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

27. Migrate existing records and train users before retiring the old system. Transition requirements enable the move between states rather than an ongoing product capability. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

28. No; classify the ongoing product behavior/quality statement, not the ordinary meaning of changing state. The course separates implementation transition needs from built-in behavior. Security statements still need careful functional/quality classification. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

29. Interview users and check the interpretation with them. Interviews, brainstorming and affinity diagramming are examples. Choose a technique for the information needed. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

30. The requirement provides a usable capability/condition that addresses the underlying need. Trace the proposed work to the problem or benefit so the team does not optimize an irrelevant feature. (Oct 26, 00:00:49-00:06:53; segments 3-15.) (Oct 26, 00:22:35-00:42:34; segments 59-126.) (Workbook, PDF pp. 49-51 and 61.)

D. Epics, stories and confirmation

31. As broad work to clarify and decompose into smaller valuable stories. The request can contain many capabilities. Decomposition and conversation make feasible delivery pieces visible. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

32. Investigate and clarify the uncertainty; lack of an estimate alone does not prove the story is a large epic. The course’s estimability test prompts refinement, but size and missing knowledge are distinct concerns. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

33. As a student, I want to filter questions by module so I can focus revision on a weak subject. The useful pattern gives a user perspective and desired value without replacing later conversation. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

34. Card, conversation, confirmation. The card opens discussion; conversation develops understanding; confirmation defines acceptance checks. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

35. Communicate user value and prompt analysis/conversation. A story is deliberately brief. Needed details and testable confirmation must still be developed. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

36. Selecting Module 5 displays only questions tagged to that module. The result can be observed and tested. It states successful behavior without unnecessarily dictating implementation. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

37. Conversation exposes rules that a short story did not specify. Supported cards, invalid responses and retries are examples of details that affect confirmation and design. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

38. Whether work can be sliced across needed layers to deliver a useful capability. The course illustrates vertical slices: the data, logic and interface needed for a bounded capability belong together. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

39. Different goals, frequency and proficiency can reveal different requirements. The workbook lists user goals, domain expertise and software familiarity as useful distinctions. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

40. Update shared understanding and testing expectations as information improves. Criteria can evolve through analysis. Discuss changes and their effect on scope, estimates and selection. (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 00:55:36-01:20:48; segments 171-244.) (Workbook, PDF pp. 51-56.)

E. Planning and activity purposes

41. Vision, roadmap, release, sprint, daily. They connect strategic direction to near-term coordination. The workbook uses a status-meeting label for the daily level; keep that course convention in context. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

42. Describe strategic rollout direction for the product/capabilities. The roadmap gives direction beyond a single sprint and can receive input from the team. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

43. A forecast of candidate stories across upcoming sprints, with priorities and relative estimates. A release plan looks farther ahead, while actual selection is revisited during sprint planning. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

44. The PO clarifies candidate work and the team selects/plans a feasible amount. The course connects prioritized input, team estimates and capacity to the sprint backlog. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

45. Clarify upcoming stories, questions and dependencies before later selection. Refinement prepares work. In November 2’s taught format it is a conversation rather than a detailed design/estimation session. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

46. Work since the last meeting, intended next work and impediments. The purpose is brief team coordination. The guide labels this as the taught format, not the only possible form of a daily collaboration meeting. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

47. Record the issue and arrange appropriate follow-up after the brief meeting. Raising an impediment is useful; solving it in depth is a separate activity for the people needed. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

48. The team, PO and relevant stakeholders inspect/demonstrate completed work and exchange feedback. The review concerns the result and stakeholder feedback. The retrospective serves a different purpose. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

49. Improve the way the team works and preserve useful practices. Discuss what worked, what did not and concrete changes. Good practices need preservation too. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

50. One to four weeks, with two to three weeks an instructor preference. This resolves the garbled October 26 minimum-duration response. It is presented as course coverage. (Oct 26, 01:50:55-02:13:23; segments 319-374.) (Nov 2, 00:55:35-00:58:05; segments 199-207.) (Workbook, PDF pp. 78-84.)

F. Backlogs, boards and burndown

51. The product backlog holds ordered potential work; the sprint backlog concerns current selected work and its execution. Their horizons and purposes differ. Selection reflects current team capacity and priorities. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

52. It returns to the product backlog for PO reprioritization. Remaining value and priority can change. Prior effort alone does not guarantee immediate reselection. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

53. Clarify urgency/value and discuss it through the PO and agreed change process. The course protects focus while allowing a reasoned response to genuine change. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

54. The Product Owner. The source gives several exceptional circumstances. It does not mean every late story or new request requires cancellation. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

55. To do, in progress, done. The board visualizes current work state. Longer-term backlog and release planning serve other horizons. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

56. Remaining work in hours against sprint days. Update remaining work to see how the sprint forecast is evolving. Time spent and remaining work are different quantities. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

57. 48 ideal remaining hours. Ideal daily burn is 80 / 10 = 8 hours. After four days, 80 - 4 × 8 = 48 hours remain. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

58. 16 hours above ideal. 64 - 48 = 16 hours above ideal. This prompts investigation; it does not by itself prove a specific cause. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

59. Remaining-work progress warrants investigation; the specific cause still needs evidence. Possible explanations include discovered work, dependency delays, capacity and estimation changes. A chart is a signal, not a root-cause proof. (Oct 26, 02:04:30-02:18:36; segments 352-386.) (Nov 2, 00:25:02-00:30:20; segments 75-90.) (Workbook, PDF pp. 81-86.)

60. It is a planning aid with exceptions, and decomposition is separate from sequencing. Workbook pp. 76-77 explicitly allow judgment. The diagram’s deliverable/activity arrangement is its course illustration. (Oct 26, 01:44:55-01:48:24; segments 303-311.) (Workbook, PDF pp. 76-77.)

G. Estimation and prioritization

61. Revise the forecast and explain changed assumptions and uncertainty. Estimates are informed forecasts. Better information should improve decisions rather than be suppressed. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

62. Cost is money charged/paid; budget allocates the estimate against scheduled work and time. The workbook contrasts a price for work with allocating that amount to a scheduled period. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

63. No; the detail of the allocation does not add new estimating evidence. A detailed-looking distribution can still inherit the original uncertainty. Use better information and suitable techniques. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

64. The workbook allows top-down or bottom-up; the October 28 lecture groups it with bottom-up. The guide preserves the difference rather than silently claiming the sources agree. Ranges are illustrative course content. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

65. Relative story size within the team’s estimating context. Points can reflect effort, complexity and uncertainty. They are not clock time or priority. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

66. Neither equal hours nor equal productivity follows from those point values alone. Point scales and work contexts are team-relative. Avoid cross-team conversion without a valid shared basis. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

67. To preserve independent judgments and reduce anchoring/groupthink. Private selection followed by shared disclosure helps surface differing assumptions. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

68. Discuss outliers and assumptions, clarify the work and estimate again. The purpose is shared understanding. Agreement should follow discussion rather than conceal uncertainty. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

69. Business value, risk, difficulty, size. The smaller-story preference applies when the other considerations are equal. Dependencies and feasibility must still be visible. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

70. Hours support task planning, organizational reporting and the taught burndown. The lecture acknowledges that experienced teams may rely more on points. It still teaches task estimates where useful or required. (Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)

H. Velocity and realistic capacity

71. 16 completed story points. Only completed stories count: 3 + 5 + 8 = 16. The partial 13-point story earns no fractional credit in this calculation. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

72. Velocity counts stories meeting the agreed completion standard. Effort and completed value are different. The work returns for priority reassessment rather than receiving completed-story credit. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

73. 18 average points per sprint. (16 + 20 + 18) / 3 = 18 points per sprint. It is a guide, not an exact quota. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

74. 3 forecast sprints. 54 / 18 = 3 sprints. This assumes comparable point scale, stable scope, team availability and working conditions. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

75. Its assumptions and uncertainty, including scope and team availability changes. Use observations to inform a forecast and update it when the relevant conditions change. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

76. A learning dry run with real work, excluded from the case’s formal metrics. It illustrates adoption and learning. Exact contradictory story counts in the spoken case are not a grading target. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

77. 150 available project hours. Each full allocation provides 60 hours. Total: 60 + 60 + 30 = 150 hours. Nominal headcount alone would overstate capacity. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

78. 126 remaining planning hours. 150 - 24 = 126 hours. The reserve must use the same units; these are not story points. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

79. Make the capacity impact visible and return unfinished work for PO reprioritization. Real availability affects selection and completion. Support effort does not turn an unfinished story into completed value. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

80. Discussing a suitable additional candidate with the PO after checking capacity and readiness. The course allows a reasoned adjustment with the PO. One quiet period does not prove future demand has disappeared. (Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Workbook, PDF pp. 115-116 and 138.)

I. Execution, quality and integration

81. A shared completion standard covering all required quality/readiness work. Unit tests may be necessary but insufficient. Definition of Done makes other completion obligations visible. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

82. Criteria confirm the particular story’s behavior; Done is the shared completion standard. Both contribute to clarity. The corporate course example includes readiness obligations beyond a narrow implementation task. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

83. Production-ready work can await actual deployment. The course distinguishes ready-to-release functionality from moving it to production under organizational rules. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

84. Collaborate and show work during the sprint while clarifying acceptance. The case’s “no surprises” lesson combines testing with early business feedback. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

85. Causes, a better completion/testing process and agreed actions, while avoiding blame. Retrospectives are a learning mechanism. Preserve what worked and act on specific improvements. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

86. Surface and coordinate the dependency, reforecast, and handle unfinished work through reprioritization. Methods do not make dependency work disappear. Integration and communication remain necessary. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

87. Coordinate the required information and approvals with organizational governance. The course keeps governance around Agile delivery while also encouraging process improvement where appropriate. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

88. Representatives coordinating dependencies and integration between Scrum teams. It is a scaling/coordination example. The unclear transcript term is corroborated by workbook p. 89. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

89. Its release/documentation effort and capacity, without hiding required unfinished quality work behind a done label. This is the supplied corporate integration example, not a blanket rule about Scrum. (Oct 28, 01:14:00-01:45:18; segments 193-264.) (Oct 26, 02:19:14-02:27:40; segments 388-405.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 86-90, 127-138 and 159-160.)

90. Coordinate the expertise, permissions and timing rather than assuming it can do the work unaided. The lecture recognizes external resources and the need for explicit arrangements. Broader collaboration is compatible with specialist boundaries. (Oct 28, 02:04:27-02:07:29; segments 309-315.) (Nov 2, 00:26:44-00:28:02; segments 79-82.) (Workbook, PDF p. 159.)

J. Organization, myths and improvement

91. Useful and necessary documentation still needs to be produced. Working value is emphasized. Support, training and governance obligations do not disappear. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

92. It can handle change through an established process, though rework and coordination can be costly. The course rejects the absolute myth while recognizing different change costs and mechanisms. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

93. No; total duration depends on scope, conditions and how the work is delivered. The lecturer’s same-scope one-year comparison is illustrative. Neither a universal speed claim nor universal equal-duration claim follows. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

94. Yes, with deliberate communication and collaboration practices. Virtual work creates challenges across approaches. Agree access, participation and collaboration habits. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

95. Participation builds shared understanding and ownership of the working agreement. Review and refine the rules as the team learns. The SM can provide starter ideas without replacing team ownership. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

96. Negotiate realistic allocation and more concentrated blocks of work where feasible. The course recognizes multitasking pressure and suggests reducing its impact rather than planning against fictional availability. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

97. Useful shorter cycles, smaller effective teams, dedication, collaboration, ground rules, management education and coaching. They are directions to evaluate, not automatic numerical rules. Changes need context and evidence. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

98. Support must include realistic expectations and respect for the new decision boundaries. The source warns about promises that Agile is easy or a cure for every problem. Informed support helps adoption. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

99. Recognize failure, learn from it and apply the lesson promptly. Learning and corrective action are the point. The phrase does not eliminate risk judgment or completion standards. (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:26:44-00:51:53; segments 79-169.) (Workbook, PDF pp. 155-161.)

100. Prioritize Modules 3-5, roles, ceremony purposes/participants and sprint structure, while recognizing the exam recollection was tentative. The guide preserves the actual study emphasis and the lecturer’s explicit qualification about an exam taken years earlier. (Nov 2, 00:55:35-00:58:05; segments 199-207.)

Using your results

Review each group separately rather than treating a total score as a certification prediction. For a missed item, explain the relevant role, artifact or unit distinction, read its cited passage and try again. For calculations, write the formula and units before substituting values. A partly finished story, a remaining-hours estimate and a release date answer different questions.