← All Reports

Dev Sprint 4 Report

Budget Tracking, Spending Breakdown, Household Management, Recurring Items
Report 2026-03-20 4 Stories Complete
4
Stories Delivered
30
Tests Passing
4
New Tests Added
1
Migration Applied

Overview

Sprint 4 delivered budget tracking and household management for Pantry App. Users can now view monthly grocery spend against a configurable budget, see spending breakdowns by store and category, manage household members and permissions, and set up recurring items for automatic restocking of staples.

The sprint introduced one new database table (recurring_items) with full RLS policies. Budget and spending features query existing budget_periods and receipts tables. Household management uses household_members with role-based access control. All 26 Sprint 3 tests continue to pass, with 4 new integration tests added covering budget queries, category breakdowns, member management, and recurring item workflows.

A pre-sprint fix enabled the Budget route in the navigation, which had been disabled since Sprint 2. All four stories passed triple-gate code review and UX validation confirmed the recurring items flow completes in 2-3 taps.

Deliverables

ID Story Detail Status
NAV-FIXEnable Budget RouteRemoved disabled: true and badge: 'Sprint 4' from Budget nav item in AuthLayout.jsxDone
BUD-001Monthly Budget TrackerMonth navigation, budget summary card with colour-coded progress bar (green/amber/terracotta), inline budget editing, receipts list with expandable item detailDone
BUD-002Spending BreakdownBy-store and by-category horizontal bar charts (pure CSS, no chart library), derived from receipts.items JSONB, sorted descending with percentage labelsDone
HSH-002Household Member ManagementHousehold name inline edit, members list with role badges (Manager/Member), action menu for role changes and removal with confirmation, current user row protectedDone
HSH-003Recurring ItemsNew recurring_items table with RLS, recurring items list on /settings with frequency badges, "Stock now" button, add/edit/delete forms, overdue highlightingDone

Key Decisions

Pure CSS Charts
Spending breakdown charts use CSS width percentages and flexbox rather than a chart library. This keeps bundle size small and avoids adding a dependency for a single feature.
Recurring Items RLS
The recurring_items table uses the existing get_user_household_ids() function for row-level security, consistent with all other household-scoped tables.
JSONB Category Aggregation
Category spending totals are derived client-side from the receipts.items JSONB array. This avoids a new server function while the data volume remains small.
Inline Budget Editing
Budget set/edit uses an inline form rather than a modal, keeping the interaction lightweight and consistent with the household name edit pattern in HSH-002.

Integration Test Coverage

30
Tests Total
26
Carried from Sprint 3
4
New this Sprint
30/30
Passing
Test ID Description Result
BUD-001-spendInsert budget_period and receipt, verify spend query returns correct totalPass
BUD-002-categoryInsert receipt with known items JSONB, verify category breakdown totalsPass
HSH-002-membersTwo users in household, verify role update and member delete via JS clientPass
HSH-003-recurInsert recurring item, trigger stock-now, verify inventory_items row created and next_due_date updatedPass

Acceptance Criteria Scorecard

BUD-001: Monthly Budget Tracker

BUD-002: Spending Breakdown

HSH-002: Household Member Management

HSH-003: Recurring Items

Sprint 4 Retrospective

Conducted at sprint close, 2026-03-20. Format: 3 standard questions plus action items.

What Went Well

  • Sprint planning was fast and thorough. PO had full AC for all 4 stories ready quickly, with 61 total acceptance criteria. Task breakdown and dependency graph were clear from the start.
  • Three parallel workstreams ran smoothly. Budget track (BUD-001/002), household settings track (HSH-002), and migration track (HSH-003) ran concurrently without blocking each other.
  • All stories passed PO sign-off with 61/61 AC items green. BUD-001, BUD-002, HSH-002, and HSH-003 all validated and approved.
  • Migration applied early, mitigating a key risk. Backend dev and DevOps coordinated well; the recurring_items table was ready before frontend needed it.
  • UX validation confirmed the recurring items flow at 2-3 taps. Grace persona target was under 4 taps, so the implementation exceeded the goal.
  • Triple-gate code review completed without major issues. Cross-review, Code Reviewer, and Lead sign-off all passed.
  • Zero regressions across all 26 existing tests. Pure CSS charts avoided a new dependency while keeping the spending breakdown clean.
  • WoW compliance held. No em dash violations, SA context (ZAR, local retailers, Lerato/Thabo/Grace personas) used consistently throughout.

What Could Be Improved

Cloudflare Pages deploy was blocked by a missing API token. The deploy credential gap identified in Sprint 3's retro was not resolved before Sprint 4 started. Deploy and smoke test are still pending.
File permission issues slowed planning docs. The docs/dev-sprint-4/ directory was root-owned, so the sprint planning doc had to live at docs/SPRINT-4-PLANNING.md instead.
Task dependency chain is long. The path from implementation to PO sign-off (code, test, review, sign-off) has 4 sequential gates. Some gates could overlap to reduce end-to-end time.
Category aggregation happens client-side from JSONB. This works at current data volumes but will need a server-side query or materialised view as receipt counts grow.

Action Items for Sprint 5

Fix directory permissions for docs/dev-sprint-5/ before sprint starts. Avoids the workaround needed this sprint.
Start deploy pipeline earlier. Do not wait for all sign-offs before the first deploy attempt. Consider adding a "deploy preview" step mid-sprint so QA can smoke test incrementally.
Resolve Cloudflare Pages API token storage. Automated deploys should not require manual credential entry. This is the second sprint where this has been flagged.
Continue the three-workstream parallelism pattern. It worked well this sprint and should be the default approach for future sprints with independent feature tracks.
Evaluate server-side category aggregation. If receipt volume grows beyond a few dozen per household per month, move the JSONB aggregation to a Supabase RPC or database view.

Retro conducted at sprint close, 2026-03-20. Actions are owned by the team going into Sprint 5.