Sprint Cadence: 18 Sprints and Counting

Sprint Structure

Vivolar’s development is organized into sprints — focused work periods with clear deliverables. Over 18 sprints, the project has grown from a basic CRUD app to a full-featured household management platform.

Each sprint follows a consistent structure:

Planning

1. Backlog refinement — review the specification’s backlog, prioritize features based on user value and technical dependencies
2. Task breakdown — decompose features into implementable tasks with clear acceptance criteria
3. Sprint document — create a markdown file (e.g., docs/plan/sprints/sprint018.md) that lists all tasks with their status

Execution

Tasks are implemented one at a time, following the TDD loop. Each task goes through:

• Implementation (backend + frontend if needed)
• Test verification (./mvnw verify + npm run build && npm test)
• Documentation update (TODO.md, sprint doc, SPECIFICATION.md if behavior changed)
• Commit with conventional format including task ID

Completion

At sprint end:

• All tasks are marked as done in the sprint document
• TODO.md is updated with completed items
• SPECIFICATION.md reflects any new behaviors
• A version bump is committed
• The sprint branch is merged to main

What Makes This Work

Single responsibility per session. A session covers one phase: planning OR implementing OR deploying. Mixing them leads to context overload and mistakes.

Documentation is part of “done.” A feature isn’t complete until its behavior is documented in the specification. This keeps the living documentation in sync with the actual system.

Conventional commits trace back to tasks. Every commit message references its task ID, creating a clear trail from requirement to implementation.

The Numbers

After 18 sprints:

• 78+ features implemented
• 29 pages in the frontend
• Multiple major architectural improvements (event-driven design, modular monolith enforcement, AI integrations)
• Consistent velocity maintained through structured process