2. Team Modes: Solo Developer vs. Scrum Team
← Back to Table of Contents | Previous: Overview | Next: Git Repo Organization →
2.1 Mode A: Solo Developer + Kiro
Profile
- 1 developer, 1 Kiro assistant
- Full ownership of all modules
- No PR review process (self-review)
Workflow
Developer defines task
↓
Kiro generates code + tests
↓
Developer reviews output
↓
Commit to short-lived branch
↓
CI validates (lint, test, build)
↓
Merge to main
Branching
main
├── kiro/auth/add-jwt-refresh
├── kiro/billing/stripe-webhook
└── kiro/infra/add-rds-module
Only one branch active at a time (or two if modules are fully isolated).
Kiro Configuration
- Single set of steering rules covering all modules
- All specs owned by the solo developer
- Hooks enforce tests on every file edit
Recommended Rhythm
| Activity |
Frequency |
| Commit |
Every 10–20 minutes |
| Branch merge |
Multiple times per day |
| Branch lifespan |
1–4 hours max |
| Terraform plan/apply |
After infra changes, before merge |
2.2 Mode B: Scrum Team (3–7 Developers) + Kiro Each
Profile
- 3 to 7 developers, each with their own Kiro assistant
- Scrum ceremonies (sprint planning, daily standup, review, retro)
- Module ownership distributed across the team
- PR review required (cross-review between team members)
Team Organization Example
| Developer |
Module |
Kiro Agent |
Branch Prefix |
| Dev 1 |
auth |
kiro-auth |
kiro/auth/ |
| Dev 2 |
billing |
kiro-billing |
kiro/billing/ |
| Dev 3 |
orders |
kiro-orders |
kiro/orders/ |
| Dev 4 |
catalog |
kiro-catalog |
kiro/catalog/ |
| Dev 5 |
frontend |
kiro-frontend |
kiro/frontend/ |
| Dev 6 |
infra |
kiro-infra |
kiro/infra/ |
| Dev 7 |
gateway / shared |
kiro-gateway |
kiro/gateway/ |
Workflow
Sprint planning → tasks assigned to modules
↓
Each Dev + Kiro works on their module
↓
Commit every 10–20 minutes
↓
PR opened → reviewed by another team member
↓
CI validates
↓
Merge to main
Scrum Adaptations for AI-Assisted Development
Sprint Planning
- Tasks are decomposed into module-scoped slices
- Each task specifies which module(s) it affects
- Cross-module tasks are split into interface + implementation parts
Daily Standup
- Each dev reports: what their Kiro generated, what they reviewed, blockers
- Focus on integration points between modules
Sprint Review
- Demo from trunk (always deployable)
- Show integration test results
Retrospective
- Review Kiro steering rules effectiveness
- Adjust module boundaries if needed
- Discuss merge conflict frequency (should be near zero)
Conflict Prevention
| Technique |
Description |
| Module boundaries |
Each Kiro only modifies its own module |
| CODEOWNERS file |
GitLab enforces review by module owner |
| High merge frequency |
Branches merged within hours |
Shared types in shared/ |
Human-maintained, not AI-modified |
| API contracts |
Modules interact only through defined interfaces |
Recommended Rhythm
| Activity |
Frequency |
| Commit |
Every 10–20 minutes |
| PR creation |
Multiple times per day |
| PR review turnaround |
< 2 hours |
| Branch lifespan |
< 24 hours |
| Trunk sync |
Continuous (rebase before PR) |
| Sprint length |
1–2 weeks |
← Back to Table of Contents | Previous: Overview | Next: Git Repo Organization →