Sprint Review — WK19
Cycle 2026-05-04 → 05-10 · Recorded in Plane as BANA-1049. The Executive Summary is sourced from git; the metrics below mirror the Plane review.
Executive Summary
Leadership takeaway
This week (04/05 – 10/05) the team kept shipping despite a third consecutive VNPAY-onsite week: the two biggest themes were the new merchant onboarding & launchpad in the client app and a commerce / inventory backbone (merchant v2, multi-level categories, units of measure, vendors, inventory locations).
- Merchant Onboarding & Launchpad — New onboarding flow with identity-verification step, auto sign-in after sign-up, organizer root and merchant launchpad, plus welcome and greeting screens.
- Commerce & Inventory Backbone — Merchant v2 creation, merchant-scoped services, multi-level categories, units of measure, vendors and vendor payment terms, inventory locations, and material aggregate with stock handling.
- Merchant Settings Suite — Merchant create/edit forms with tax-code check, city/wards, e-invoices, finance wallet, payment settings, and sale-channel sections.
- Product Workspace — New product module, product list and basic-info forms, category select, draft status, and per-location stock options.
- Search & CDC Reliability — Search-engine integration for the launchpad, plus a Kafka circuit breaker, transient-vs-permanent error classification, and backlog heartbeat logging.
- Identity & Licensing — Phone-OTP template service, unlink phone/email, token returned on sign-up, and free-trial license issuance.
- Helpdesk & Tax — SLA-policy management with receipt-template services, the initial helpdesk schema, and VN administrative-unit / tax-info CDC into invoicing.
Sprint context — continued VNPAY onsite pivot (3 weeks total)
WK17, WK18, and WK19 all ran with 5 VNPAY POs onsite at NEXPANDO. The team worked direct with them on the MVP delivery; planned tasks/bugs were put on hold to prioritize VNPAY requests for the full 3-week period.
- WK19's 100-item plan was never realistic given continued VNPAY load. The plan-of-record decoupled from the work-of-record.
- The 66 carry-over items are deferred-for-VNPAY, not delivery failure.
- WK20 is the first restart cycle — VNPAY pivot ends, normal cadence resumes.
Read every "low completion" / "carry-over" number below against this pivot.
Health Score: 23/100 — by the numbers (not a process verdict)
| Dimension | Score | Weight | Contribution |
|---|---|---|---|
| Completion | 40.0/100 | 30% | 12.0 |
| Predictability | 0/100 | 25% | 0.0 |
| Workload Balance | 2.6/100 | 20% | 0.5 |
| Flow (no carry-over) | 0/100 | 15% | 0.0 |
| Quality (no cancel) | 100/100 | 10% | 10.0 |
Mathematically correct against the WK19 plan but does not reflect actual outcome. Treat as: "the cycle's plan-of-record was overtaken by continued VNPAY engagement."
Delivery
| Metric | WK19 | WK18 | 4-cycle avg | Target | Note |
|---|---|---|---|---|---|
| Committed | 100 | 13 | 53.5 | — | Plan set without acknowledging continued VNPAY load |
| Completed | 34 | 12 | 35 | — | Team produced its usual output (~34/wk) |
| Completion % | 34.0% | 92.3% | 77.5% | 85% | Pivot, not failure |
| Cancelled | 0 (0%) | 1 (7.7%) | 2.5 | <7% | ✅ |
| Carried over | 66 (66%) | 0 | 16.5 | <10% | Deferred for VNPAY |
| Throughput/member | 2.8 | 1.0 | 2.9 | 2.0 | ✅ raw output OK |
Verdict: team produced its usual output (~34 items). The plan never matched reality given VNPAY load. WK19 was a continued-pivot week, not a delivery collapse.
Team Breakdown
Sums >100 because items have multiple assignees. Read against the pivot.
| Member | Total | Done | Carry | Done % | Load /5 | Flag |
|---|---|---|---|---|---|---|
| Hai | 38 | 3 | 35 | 7.9% | 38/5 | 🔴 OVERLOADED + LOW COMPLETION |
| Phat.N | 38 | 12 | 26 | 31.6% | 38/5 | 🔴 OVERLOADED + LOW COMPLETION |
| Khoa | 28 | 7 | 21 | 25.0% | 28/5 | 🔴 OVERLOADED + LOW COMPLETION |
| Bach | 12 | 4 | 8 | 33.3% | 12/5 | 🔴 OVERLOADED + LOW COMPLETION |
| Thuong | 7 | 5 | 2 | 71.4% | 7/5 | 🟡 OVERLOADED |
| Tai | 6 | 1 | 5 | 16.7% | 6/5 | 🟡 OVERLOADED + LOW COMPLETION |
| Phuc.D | 6 | 0 | 6 | 0% | 6/5 | 🔴 OVERLOADED + LOW COMPLETION |
| Huy | 4 | 3 | 1 | 75.0% | 4/5 | ✅ |
| Viet | 4 | 0 | 4 | 0% | 4/5 | 🔴 LOW COMPLETION |
| Toan | 3 | 0 | 3 | 0% | 3/5 | 🔴 LOW COMPLETION |
| Kien | 3 | 3 | 0 | 100% | 3/5 | ✅ |
| Phat.C | 1 | 0 | 1 | 0% | 1/5 | 🔴 LOW COMPLETION |
Workload max/min ratio = 38× — far above the 3× threshold. Real problem regardless of pivot.
Carry-Over Age Analysis (66 items)
Of 66 not-done items, ~36 are ≥3 weeks old (template rule: MUST split or cancel):
| Age | Count | Rule | Items |
|---|---|---|---|
| ≥10 weeks (zombie cluster) | 5 | MUST cancel | BANA-344, 509, 512, 516, 538 |
| 5-9 weeks | 16 | MUST split or cancel | BANA-620, 621, 628, 677, 704, 705, 729, 730, 750, 756, 759, 760, 764, 770, 772, 781 |
| 3-4 weeks | ~15 | MUST split or cancel | BANA-789, 792, 793, 801, 803, 810, 855, 872, 876, 890–894, 902–907, 926, 928, 930 |
| 2-3 weeks | ~17 | review with assignee | BANA-932–938, 944, 945, 964–975 |
| <2 weeks | ~13 | safe to transfer | BANA-985–987, 1030, 1037 |
The WK17 review already flagged 9 zombies (BANA-216, 344, 509, 512, 516, 538, 620, 621, 628). 8 are still alive in WK19 — no decision was forced. These predate the VNPAY pivot — not excused.
4-Cycle Trend
| Metric | WK16 | WK17 | WK18 | WK19 | Direction |
|---|---|---|---|---|---|
| Committed | 65 | 36 | 13 | 100 | volatile |
| Completed | 58 | 34 | 12 | 34 | ■ flat output |
| Completion % | 89.2% | 94.4% | 92.3% | 34.0% | ▼ pivot |
| Carry-over | 0 | 0 | 0 | 66 | ▲▲▲ pivot accumulation |
Team's actual delivery rate is steady (~34 items/wk). Plan-of-record decoupled from reality during 3-week VNPAY pivot.
Recommendations for WK20 (the restart)
- WK20 = restart cycle. Set capacity to ~40 items. Don't run another oversized sprint just because VNPAY pivot ended.
- Force-cancel the 5 zombie items (BANA-344, 509, 512, 516, 538) — they've outlived their original context.
- Triage carry-over before WK20 commits — split, cancel, or commit. No more "transfer and hope."
- Rebalance Phat / Hai / Khoa — three people each carrying 28-38 items is structurally broken regardless of VNPAY.
- Pivot protocol for future onsite engagements — when an unplanned engagement consumes >2 days of team capacity, explicitly cut the sprint plan at the start. Don't run two plans in parallel.
- Skip "Intervention required" retrospective — Health Score is misleading here. Run a brief VNPAY post-mortem instead: what shipped, what feedback came back, what to fold into WK20-22.
Action Triggers — re-read against pivot
| Trigger | Fired | Verdict |
|---|---|---|
| Completion <75% (1 cycle) | ✅ | 🟡 Pivot context — watch WK20 to see if it persists |
| Completion <75% × 2 cycles | not yet | WK20 is the test |
| Member >5 items | ✅ | 🔴 Real problem regardless of pivot — fix |
| Carry-over age >2 wk | ✅ (~36 items) | 🔴 Real problem — predate pivot — fix in WK20 triage |
| Cancellation >15% | — | ✅ |
| Workload max/min >3× | ✅ (38×) | 🔴 Real problem regardless of pivot — fix |
| Health Score <60 | ✅ (23) | Misleading — see Context note |
Related Pages
- Sprint Reviews · Roadmap · Changelog · Traceability Matrix
- Plane: BANA-1049 — Sprint review 2026_WK19 (Report)