Kiro Methodology

12. Daily Operational Rhythm

← Back to Table of Contents | Previous: File Hierarchy | Next: Quick Reference →

12.1 Solo Developer Daily Rhythm

Time Activity
Start of day Pull latest main, review overnight CI results
Morning Define tasks for the day, create Kiro specs
Throughout day Kiro generates → review → commit → merge (every 1–2 hours)
End of day Ensure all branches are merged, main is green

Solo Commit Cadence

09:00  Pull main, plan tasks
09:15  Create branch kiro/auth/add-login
09:30  Kiro generates login service + tests → commit
09:45  Kiro generates login controller + tests → commit
10:00  Review, adjust, open PR → CI → merge
10:15  Create branch kiro/auth/add-token-refresh
...

Target: 4–8 merges to main per day.

12.2 Scrum Team Daily Rhythm

Morning (Sync)

Time Activity
09:00 Daily standup (15 min)
09:15 Sync on integration points between modules
09:30 Each dev starts their module work

Standup Format (AI-Adapted)

Each developer reports: 1. What Kiro generated yesterday and what was merged 2. What module work is planned today 3. Any cross-module dependencies or blockers

During Day (Parallel Work)

Dev 1 + Kiro-auth:     branch → generate → test → commit → PR → review → merge
Dev 2 + Kiro-billing:  branch → generate → test → commit → PR → review → merge
Dev 3 + Kiro-orders:   branch → generate → test → commit → PR → review → merge
...all working in parallel, merging multiple times per day

PR Review Turnaround

Priority Target
Small PR (< 100 lines) Review within 1 hour
Medium PR (100–300 lines) Review within 2 hours
Large PR (300+ lines) Split into smaller PRs

End of Day (Stabilize)

Time Activity
17:00 All branches merged or abandoned
17:15 Integration tests run on main
17:30 main is confirmed green and deployable

12.3 Sprint Ceremonies (AI-Adapted)

Sprint Planning (2 hours)

  1. Review product backlog
  2. Decompose stories into module-scoped tasks
  3. Assign module ownership for new tasks
  4. Identify cross-module dependencies
  5. Estimate considering AI-assisted velocity (typically 2–3x faster)

Sprint Review (1 hour)

  1. Demo from main (deployed to staging)
  2. Show test coverage metrics
  3. Review architecture health (any boundary violations?)

Retrospective (1 hour)

  1. Were Kiro steering rules effective?
  2. Any merge conflicts? (should be near zero)
  3. Any module boundary violations?
  4. Should we adjust module ownership?
  5. Are tests catching real issues?

12.4 Weekly Infrastructure Review

Once per week (or per sprint):

  1. Review Terraform plan for each environment
  2. Check for infrastructure drift
  3. Update Terraform modules if needed
  4. Review AWS costs and resource utilization

12.5 Key Metrics to Track

Metric Target Why
Merges to main per day 4–8 per developer High frequency = healthy trunk
Branch lifespan < 24 hours Short branches = fewer conflicts
PR review turnaround < 2 hours Fast reviews = fast merges
Test coverage > 80% per module Tests are the safety net
CI pipeline duration < 15 minutes Fast feedback loop
Merge conflicts per week < 2 Module isolation is working
Failed deployments 0 Trunk is always deployable

← Back to Table of Contents | Previous: File Hierarchy | Next: Quick Reference →