Capstone: Running a Sprint from Planning to Retrospective
The Software Development Lifecycle
Chapter 10 · Capstone: Running a Sprint from Planning to Retrospective
One continuous worked sprint: adding loyalty-point redemption to Clean Code, SOLID & Refactoring's own TangleMart order system — the same system Software Testing Strategy's own capstone already extended with point-earning. Every technique from Chapters 1 through 9 gets applied to this one real piece of work, in the order a real sprint actually forces, closing with the finished feature verified end to end against its own acceptance criteria.
Step 1Lightweight Process (Chapter 1)
Verified directly — the backlog entry carries a recorded reason before any work starts
"addresses ticket #2044 - GOLD members asked how to use their points" — recorded reason: present, avoiding Chapter 1's own verified 80%-untraceable outcome under no process, without imposing Chapter 1's own 61x heavy-process tax on a normal feature request.
Step 2Early Check-In (Chapter 2)
Verified directly — checking in after 2 of 6 subtasks avoided 67% of this sprint's own rework
Waterfall (no check-in until the end): 6 of 6 subtasks would need rework once a redemption-rate misunderstanding surfaces. Checking in after every 2 subtasks: only 2 of 6 — 67% of rework avoided, the same mechanism Chapter 2 verified generally, now applied to this sprint's own real subtasks.
Step 3Sprint Planning & Daily Standups (Chapter 3)
Verified directly — the sprint committed to exactly known velocity and completed 100%; a same-day standup cut a blocker from 7 days lost to 1
Committing to 20 points against a known velocity of 20.0: 20 completed, 100%. A blocker on day 3 (payments team must confirm points can't go negative): with a daily standup, 1 day lost; without one, 7 days lost — the exact mechanism Chapter 3 verified, now catching a real edge case in this sprint's own work.
Step 4WIP Discipline (Chapter 4)
Verified directly — a WIP limit of 1 across this sprint's own 6 subtasks kept cycle time at Little's Law's own minimum
WIP=1: 60 minutes total, 10.0-minute average cycle time. WIP=6 (juggling all subtasks at once): 237 minutes total, 229.5-minute average cycle time — the same WIP-vs-cycle-time relationship Chapter 4 verified generally, confirmed again on this sprint's own real subtask list.
Step 5The User Story (Chapter 5)
Verified directly — the story is independent, appropriately small, and its acceptance criteria already is a BDD scenario
"As a GOLD member, I want to redeem my loyalty points for a checkout discount, so that I feel rewarded for repeat purchases." Independent of other in-sprint work: confirmed. Sized at 8 points against a 20-point sprint: fits safely alongside other work. Acceptance criteria: "Given a GOLD member with 40 points, When they redeem all 40 at checkout, Then a $4.00 discount is applied" — already Given-When-Then, per Chapter 5's own finding.
Step 6Planning Poker (Chapter 6)
Verified directly — simultaneous reveal surfaced a hidden complexity anchored estimation diluted to invisibility
One developer knows about a rounding edge case in the points data model, worth 13 points, not the 5 everyone else assumes. Anchored estimation: final estimate 5.6 — the concern nearly vanishes. Planning poker: [5, 5, 5, 5, 13], an 8-point spread that triggers discussion — the team agrees on 13, the real complexity, not the anchored 5.6.
Step 7Code Review (Chapter 7)
Verified directly — a style-only checklist approved the exact composed-bug risk a smell-aware, teaching review caught and blocked
preview_redemption_discount and apply_redemption_discount, well-formatted and well-named: style-only checklist approves. Smell-aware checklist: flags duplicated validation+calculation logic — the same Extract Method risk Clean Code Chapter 8 catalogued, and the same composed-bug shape Software Testing Strategy Chapter 1 verified. It blocks merge (a real duplication-drift risk, not a nit), with the reviewer explaining why rather than just rejecting.
Step 8The Architecture Decision (Chapter 8)
Verified directly — the expected-cost formula correctly separated a decision worth an ADR from one that wasn't
Where the points balance lives (a new field vs. a separate table) — reversal cost 40 hours: expected cost with an ADR 8.00h vs. without 12.00h — writing it is the better choice. Which HTTP status code the endpoint returns — reversal cost 1 hour: expected cost with an ADR 2.15h vs. without 0.30h — skipping it is the better choice. The same formula, two genuinely different real decisions from the same sprint, two correctly different answers.
Step 9The Retrospective (Chapter 9)
Verified directly — the recurring blocker pattern got a real, tracked action item, raised blamelessly
Owner: Scrum Master. Due: next sprint planning. Fix: "flag any story touching balances for payments review at sprint planning, not during the sprint." Raised blamelessly — crediting the planning-poker catch rather than asking why the risk wasn't obvious to everyone from the start, exactly Chapter 9's own verified reporting-rate finding in practice.
Final Integration: The Feature, Verified Against Its Own Story
Verified end to end — every value matches the story's own acceptance criteria, and the review's own fix closed the exact risk it named
The reviewed, extracted calculate_redemption_discount(): preview and actual both return $4.00 for 40 redeemed points — identical, closing the duplication-drift risk Step 7 flagged. Negative points: correctly rejected, closing Step 3's own standup blocker. A full checkout — $41.00 order total, minus the $4.00 redemption — correctly totals $37.00.
Where This Connects
| This capstone's step | Direct connection |
|---|---|
| A composed-bug-shaped review finding | Software Testing Strategy Chapter 1's own $1799.10-instead-of-$17.99 finding — the same risk shape, caught here before it ever shipped |
| The reused TangleMart system itself | Clean Code, SOLID & Refactoring's own capstone and Software Testing Strategy's own capstone — three courses' worth of capstones building on the identical codebase |
| The ADR decision rule | Software Architecture Fundamentals Chapter 9's own ADR format — Chapter 8 of this course added the timing/worth-it question that format doesn't answer on its own |
Hands-On Exercises
Exercise 1
Add a second user story to this chapter's own sprint: "As a PLATINUM member, I want to see my points balance on the order confirmation page." Determine whether it's independent of the redemption story, estimate it at a plausible point value, and verify the sprint's own total commitment still fits within the 20-point known velocity.
📄 View solutionExercise 2
Using this chapter's own ADR expected-cost formula, determine the reversal-cost threshold above which writing an ADR becomes the better choice for a decision made during this sprint, using the chapter's own risk parameters.
📄 View solutionExercise 3
Extend this chapter's own final integration check with a second redemption in the same sprint — a PLATINUM member with 25 points redeeming all 25. Verify the discount amount, verify it doesn't affect the first GOLD member's own already-completed redemption, and verify negative-point rejection still works for this second customer too.
📄 View solutionChapter 10 Quick Reference — Course Summary
- Verified end to end: one real sprint — a loyalty-points-redemption feature — carried through all 9 prior chapters' own techniques, each directly reusing that chapter's own verified formula on fresh, real inputs
- Step 2 avoided 67% of rework by checking in early instead of waiting for the sprint review
- Step 6's planning poker surfaced a hidden 13-point complexity that anchored estimation diluted to 5.6
- Step 7's review caught the exact composed-bug risk Software Testing Strategy Chapter 1 first verified, before it ever shipped
- Step 8's formula correctly separated a genuine ADR-worthy decision from a trivial one, using the same rule twice with two different real answers
- Course complete: process cost, Agile foundations, Scrum, Kanban, requirements, estimation, code review, ADRs, and retrospectives — all ten chapters, verified throughout
- Subject complete: this closes the Software Development subject's entire original seven-course scope