Version 1.0 · 4 November 2026
Robert Clines · Four sessions: October 21, 26, 28 and November 2. Based on the supplied 187-page version 8.0 workbook, including its slides. Use the Complete Guide for explanation and the Source Index for source differences. PDF pages count the cover as page 1.
The instructor highlighted Modules 3-5, roles, ceremony purpose/participants and sprint structure. These recall pairs retain course qualifications; they are not an official exam specification. All worked arithmetic in the practice bank is editorial.
Approaches and feedback
(Oct 21, 00:24:58-00:53:19; segments 133-198.) (Workbook, PDF pp. 17-22.)
| Prompt | Recall |
|---|---|
| Agile / adaptive | Plan, deliver and learn in smaller pieces so feedback can guide change. |
| Predictive / plan-driven | Coordinate a sufficiently understood result and sequence through advance planning. |
| Hybrid approach | Deliberately combine approaches to meet different delivery needs. |
| Iterative work | Revisit and improve a solution using feedback; the focus is suitability/correctness. |
| Incremental work | Add completed, tested, usable portions of the result. |
| Prototype | A model for learning and feedback; not automatically a production-ready increment. |
| Rolling-wave planning | Plan near work in more detail and revisit later work as understanding improves. |
| Method-selection questions | What can be delivered separately, what is uncertain, what is fixed, and how will feedback change decisions? |
| Fixed deadline in Agile | Possible; examine feasible scope, resources, risks and dependencies instead of deciding from the date alone. |
| Methodology limitation | An approach cannot fix underlying delivery problems that remain unaddressed. |
| Individuals and interactions | Preferred over processes and tools; useful process and tools still matter. |
| Working software | Preferred over comprehensive documentation; necessary documentation still matters. |
| Customer collaboration | Preferred over contract negotiation; contracts are not eliminated. |
| Responding to change | Preferred over following a plan; plans are revised, not abolished. |
Framework recognition
(Oct 21, 01:00:26-01:10:42; segments 220-245.) (Workbook, PDF pp. 23-25.)
| Prompt | Recall |
|---|---|
| Scrum | Agile framework organized around sprints, backlogs, roles and recurring collaboration/inspection. |
| DSDM constraint pattern | The course fixes cost and schedule and lets scope flex. |
| Timeboxing | Limit available time and select feasible work to fit. |
| Kanban emphasis | Prioritize flow and limit work in progress. |
| XP practices in the course | Pairing, continuous testing, test-driven feedback and responsiveness to change; workbook co-location claims are course-specific. |
| FDD emphasis | Use models and a feature list to plan/design/build small features linked to business needs. |
People and decision boundaries
(Oct 21, 01:16:49-01:25:59; segments 258-278.) (Oct 26, 00:21:13-00:22:09; segments 56-57.) (Workbook, PDF pp. 27-29.)
| Prompt | Recall |
|---|---|
| Product Owner | Clarifies business needs and orders the product backlog to support value. |
| Scrum Master | Coaches/facilitates, helps remove impediments and protects focus; does not dictate every task. |
| Team members | Estimate/select feasible sprint work, organize execution and bring the skills needed to deliver. |
| PO versus BA | A BA may be a PO; the lecture explicitly says a PO need not be a BA. |
| Product priority decision | The PO works with the business to decide the order of product work. |
| Feasible sprint amount | The team determines what it can accomplish using estimates, availability and dependencies. |
| Self-management | Responsibility for organizing and doing work within shared priorities and obligations. |
| Cross-functionality | Cover needed delivery skills collaboratively; coordinate specialists/access when needed. |
| Course team-size preference | Nine or fewer team members if possible; an instructor convention, not a universal Scrum standard. |
| External PM coordination | Where used, connect budget, reporting, approval, dependency and release work to team delivery. |
Requirements and stories
(Oct 26, 00:22:35-00:26:51; segments 59-67.) (Oct 26, 00:43:02-00:53:06; segments 130-156.) (Oct 26, 01:06:28-01:20:48; segments 207-244.) (Workbook, PDF pp. 49-56.)
| Prompt | Recall |
|---|---|
| Need | The underlying problem or desired benefit. |
| Requirement | A capability or condition that addresses a need, specific enough for its intended use. |
| Elicitation | Collaborate, ask, clarify and check understanding throughout the work. |
| Gathering risk | Recording initial requests and disappearing can preserve misunderstandings. |
| Elicitation technique examples | Interviews, brainstorming and affinity diagramming. |
| Four requirement categories | Business, stakeholder/end-user, solution and transition. |
| Business requirement | The business goal or reason for change. |
| Stakeholder requirement | A need from a particular user or stakeholder group. |
| Functional solution requirement | What the solution does: its behavior or capability. |
| Non-functional solution requirement | A quality, performance or operating condition; classify the actual statement carefully. |
| Transition requirement | A temporary capability needed to move to the new state, such as migration or training. |
| Epic | A large story that needs decomposition before its pieces can be estimated and delivered. |
| Epic caution | A small unclear story may need investigation; inability to estimate alone does not prove large size. |
| User-story template | As a [role], I want to [capability], so that [benefit]. |
| User-story purpose | State user value and prompt conversation; not a complete technical specification. |
| Card | Briefly capture the story and its intended user/value. |
| Conversation | Clarify assumptions, needs, exceptions and implementation questions together. |
| Confirmation | Agree observable checks that demonstrate acceptance. |
| Acceptance criteria | Story-specific conditions guiding testing; make success checkable without unnecessarily prescribing design. |
| Good-story characteristics | User value, understandable language, a clear user goal, conversation and testable confirmation. |
| Multiple user perspectives | Different goals, usage frequency and proficiency can reveal different requirements. |
| Usable vertical slice | Deliver the interface, logic, data and testing needed for one useful capability together. |
Planning and activities
(Oct 26, 01:50:55-02:13:23; segments 319-374.) (Workbook, PDF pp. 78-84.)
| Prompt | Recall |
|---|---|
| Five course planning levels | Vision, roadmap, release, sprint and daily. |
| Vision | High-level goal and reason for the work. |
| Roadmap | Strategic sequence for rolling out the product/capabilities. |
| Release planning | PO/team forecast candidate capabilities across several sprints for a release. |
| Sprint planning | PO clarifies priority/context; team estimates and selects feasible work and plans execution. |
| Daily stand-up purpose | Brief team coordination and impediment visibility; use the course’s three prompts without turning it into manager permission-seeking. |
| Course daily prompts | What did I do since the last meeting? What next? What impediments do I face? |
| Course daily timebox | 15 minutes or less; the taught facilitation format is a course convention. |
| Detailed problem solving | Arrange follow-up after raising the issue; protect the brief daily meeting. |
| Backlog refinement / story time | PO/team clarify upcoming stories, dependencies and questions before later selection. |
| Refinement is not selection | Preparing a candidate does not guarantee it will be selected for a future sprint. |
| Sprint review | Team, PO and stakeholders inspect/demonstrate the completed result and exchange feedback. |
| Sprint retrospective | Team examines its way of working, preserves successes and agrees improvements; SM facilitates in the course model. |
| Review versus retrospective | Review inspects the product/result; retrospective improves the process/teamwork. |
| No surprises at review | Collaborate and demonstrate during the sprint, instead of first seeking stakeholder feedback at the final review. |
| Course sprint duration | One to four weeks; two to three weeks is the instructor preference. |
| Release versus sprint | A release may package results from multiple sprints; completion and deployment dates can differ. |
| Course sprint termination authority | Only the Product Owner in the taught exceptional scenario; new requests do not automatically require cancellation. |
Artifacts, progress and change
(Oct 26, 02:04:30-02:18:36; segments 352-386.) (Workbook, PDF pp. 81-86.)
| Prompt | Recall |
|---|---|
| Product backlog | Ordered potential product work, evolving as priorities and understanding change. |
| Sprint backlog | Work selected for the current sprint plus its execution details. |
| Unfinished story | Return it to the product backlog for PO reprioritization; no automatic next-sprint priority. |
| Mid-sprint new request | Clarify urgency/value with the PO and use the agreed change process instead of silently adding work. |
| Task board columns | Common course example: to do, in progress, done. |
| Sprint task board horizon | Shows the current sprint’s work; product/release planning has a broader horizon. |
| Burndown axes | Remaining work against elapsed sprint days; the course uses hours. |
| Ideal burndown endpoint | Zero remaining work at the planned end of the sprint. |
| Burndown above ideal | Investigate remaining work, capacity, dependencies and uncertainty; the line alone does not identify a cause. |
| WBS versus sequence | A decomposition identifies work/deliverables; sequencing and dependencies are separate decisions. |
| 8/80 course guideline | A sizing aid with exceptions, not a universal rule prohibiting smaller or larger activities. |
Estimation and prioritization
(Oct 28, 00:01:24-00:42:26; segments 4-120.) (Workbook, PDF pp. 111-116.)
| Prompt | Recall |
|---|---|
| Estimate | An informed forecast with uncertainty; revise it when evidence changes. |
| Cost in this course | Money charged/paid for the work. |
| Budget in this course | The estimate allocated against scheduled work and time. |
| Top-down estimation | Estimate the overall work first; splitting that number does not independently improve accuracy. |
| Bottom-up estimation | Estimate detailed pieces and aggregate them. |
| Analogous estimation | Use comparable previous work to inform the estimate. |
| Parametric estimation | Apply a relevant rate or relationship to quantities of work. |
| Expert judgment | Use informed expertise and its assumptions. |
| Three-point estimation | Consider optimistic, most-likely and pessimistic outcomes; workbook also lists PERT. |
| Story points | Relative story size in a team’s context; not hours and not directly interchangeable across teams. |
| Relative sizing considerations | Effort, complexity, uncertainty, dependencies and what complete means. |
| Modified estimation scale | The workbook uses Fibonacci-style values including 0/100 endpoints; not every card is an exact Fibonacci number. |
| Task-hour estimates | Estimate task work/duration as needed for sprint planning, reporting and the course burndown. |
| Planning Poker independence | Select estimates privately, then reveal together to reduce anchoring/groupthink. |
| Planning Poker disagreement | Discuss assumptions and outliers, then re-estimate; avoid pressure to conform. |
| Course priority order | Business value, risk, difficulty, size. |
| Smaller-story preference | Prefer smaller work when other priority considerations are equal. |
| Preliminary estimate source difference | Workbook allows top-down or bottom-up; October 28 lecture groups it with bottom-up. |
Velocity, done and capacity
(Oct 28, 00:42:29-00:48:20; segments 121-134.) (Oct 28, 02:08:08-02:11:55; segments 317-326.) (Nov 2, 00:32:45-00:35:21; segments 97-105.) (Workbook, PDF pp. 113-116 and 159-160.)
| Prompt | Recall |
|---|---|
| Velocity calculation | Sum story points of completed stories in the sprint. |
| Partial-story velocity credit | None in the course calculation; count only stories meeting the agreed completion standard. |
| Average velocity | Use several comparable sprints as a forecast guide; not an exact quota. |
| Velocity forecast assumptions | Comparable scope/points, team availability and working conditions; changes can alter the forecast. |
| Calibration sprint in the workbook | Learning dry run with real work, excluded from the case’s formal metrics; not a mandatory extra Scrum event. |
| Definition of Done | Shared completion standard that makes required quality/readiness work explicit. |
| Done versus acceptance criteria | Done is the shared completion standard; acceptance criteria confirm the particular story’s behavior. |
| Production-ready versus deployed | Ready work can await the next authorized release window. |
| Corporate readiness example | Needed testing, scripts, approvals, documentation, training, communication and packaging are complete before release. |
| Actual availability | Plan from allocated time, absences and other obligations, not headcount alone. |
| Production-support reserve | Use recent demand to reserve realistic capacity; the instructor suggests averaging four iterations. |
| Support exceeds reserve | Reassess capacity; unfinished stories return for PO reprioritization. |
| Hours versus points | A capacity reserve in hours is not the same number of story points. |
Organization and improvement
(Oct 28, 01:45:22-02:08:06; segments 265-316.) (Nov 2, 00:01:53-00:20:08; segments 5-48.) (Nov 2, 00:35:53-00:51:53; segments 108-169.) (Workbook, PDF pp. 87-90, 136-138 and 155-161.)
| Prompt | Recall |
|---|---|
| Agile documentation myth | Needed documentation still exists; working value is emphasized. |
| Agile planning myth | Planning is distributed across horizons and repeated as understanding improves. |
| Agile discipline myth | Self-management increases responsibility to coordinate and deliver. |
| Distributed-team myth | Agile can use virtual teams with deliberate collaboration practices. |
| Scaling example | Scrum of Scrums coordinates representatives around dependencies between teams. |
| Waterfall change myth | Predictive work can handle change through an established, often more formal process. |
| Automatic speed myth | Earlier usable increments do not guarantee a shorter total project duration. |
| Magic-cure myth | Agile adoption needs skills, discipline, management support and attention to root causes. |
| Organizational governance | Budgets, reporting, approvals and release obligations continue around Agile delivery. |
| Hardening-sprint example | Workbook release/documentation integration practice; plan its effort and do not hide unfinished required quality work. |
| Context-switching response | Use realistic allocations and concentrated work blocks where feasible. |
| Virtual-team habits | Agree participation, access and communication practices; strengthen relationships and include remote members. |
| Team ground rules | Team creates and revisits shared working agreements; outside imposition alone weakens ownership. |
| Improvement targets | Useful shorter cycles, smaller effective teams, dedication, collaboration, ground rules, management education and coaching. |
| Management education | Set realistic expectations and respect decision boundaries instead of promising an easy cure. |
| Coaching and mentoring | Share learning and help teams build capability; consider disruption when moving experienced members. |
| Fail fast | Detect, learn and apply the lesson promptly so the same failure is not repeated. |