Software Development Process: Agile, Scrum, and What Actually Works at Scale

Every engineering team says they do Agile. Most of them don't — they do "Agile theater": standups without outcomes, sprints without definitions, retrospectives without change. The ceremonies exist; the benefits don't.

This guide is about what actually works. Not the textbook version of Scrum, but the adapted, pragmatic process that high-performing teams use to ship reliably, maintain quality, and not burn out their engineers.

---

Agile vs. Scrum vs. Kanban

These terms are often used interchangeably. They're not the same thing.

The honest take: Scrum works well for product development with clear priorities and 2-week cycles. Kanban works well for platform/infrastructure teams and support queues. SAFe is expensive overhead that most companies would be better off avoiding. Whatever you choose, the actual values matter more than the ceremonies.

---

The Sprint Structure That Works

Sprint length: 2 weeks for most teams. 1 week if you're in rapid product discovery mode. 4 weeks creates too much uncertainty and delayed feedback.

Week 1

Monday:
  - Sprint planning (2 hours for 2-week sprint)
    - Review sprint goal: one sentence, not a list of tickets
    - Pull stories from backlog, discuss, estimate, commit
  - Engineering work begins

Tuesday–Friday:
  - Engineering work
  - Daily standup: 15 minutes max (not a status meeting — a coordination meeting)
  - Async: daily async standup via Slack instead of sync is often faster

Week 2

Monday–Wednesday:
  - Engineering work continues
  - Bug triage: any bugs found in sprint go to current sprint, not backlog

Thursday:
  - Feature freeze: code complete, deployed to staging
  - QA / testing

Friday:
  - Sprint review (30–60 min): demo to stakeholders, collect feedback
  - Retrospective (45–60 min): process improvements
  - Release to production
  - Backlog grooming (informal): prep for next sprint planning

---

Definition of Done (The Most Important Artifact)

A story is "done" when the entire team agrees on what "done" means. Without this, "done" means whatever the last person who touched it decided.

Sample Definition of Done:

## Definition of Done

A story is Done when:

### Code
- [ ] Feature implemented per acceptance criteria
- [ ] Unit tests written (coverage ≥ 80% for new code)
- [ ] Integration tests written for new API endpoints
- [ ] No new TypeScript errors (`npm run typecheck` passes)
- [ ] No new lint errors (`npm run lint` passes)
- [ ] Code reviewed by at least 1 other engineer
- [ ] No TODO comments left in code (or tracked as follow-up tickets)

### Testing
- [ ] Tested manually in staging environment
- [ ] Edge cases tested (empty state, error state, boundary values)
- [ ] Works on mobile (if UI change)
- [ ] Works in Chrome, Firefox, Safari (if UI change)

### Deployment
- [ ] Deployed to staging
- [ ] No regressions found in staging
- [ ] Database migrations tested (if any)

### Documentation
- [ ] API documentation updated (if API changed)
- [ ] README updated (if setup process changed)
- [ ] Relevant stakeholders notified of changes

### Acceptance
- [ ] Product owner or stakeholder has accepted the story

Print this out. Put it in your Notion/Confluence. Reference it in code review. It sounds bureaucratic — it's actually liberating. Disagreements about whether something is "done" are resolved by the checklist, not by personalities.

---

Story Estimation: Points vs. Hours

Story points (1, 2, 3, 5, 8, 13) measure relative complexity, not time. A 3-point story isn't "3 hours" — it's "more complex than a 2-point but less than a 5-point."

T-shirt sizing (XS, S, M, L, XL) is faster and often more accurate for early backlog grooming.

Hours for individual tasks during sprint planning (not story estimation) — useful for capacity planning.

The reason experienced teams prefer points over hours: engineers are consistently bad at estimating hours but reasonably good at relative complexity. A team's velocity (points/sprint) stabilizes over 3–4 sprints and becomes a reliable forecast tool.

Sprint capacity example:
- 4 engineers × 2 weeks × 60% focused development time = 4 × 10 × 0.6 = 24 days
- Historical velocity: 40 story points per sprint
- Relationship: ~1.67 story points per engineer-day
- Use this to right-size sprint commitments — not gut feel

---

Code Review Culture

Code review is the highest-leverage quality practice in most teams — and one of the most frequently done poorly.

Review What Matters

Good code review feedback:

• "This function has O(n²) complexity — here's a linear alternative: ..."
• "This mutation pattern will cause race conditions with concurrent requests. Consider: ..."
• "This field name conflicts with a reserved JS keyword. Consider userCount instead of count."
• "Missing error handling — what happens if db.users.findOne() returns null?"

Bad code review feedback:

• "I would have done this differently."
• "This could be more elegant."
• "We usually use single quotes." (That's what linters are for.)
• "LGTM" without substantive review.

Review Response Time

Code review latency is a major drag on team velocity. Establish norms:

• Author: request review promptly after CI passes (not 4 hours later)
• Reviewer: respond within 4 working hours (not 2 days)
• Author: address feedback and re-request promptly
• Use async review (GitHub/GitLab comments), not synchronous review sessions

PR Size

Small PRs are reviewed better and merged faster. Target < 400 lines changed per PR. Large features should be feature-flagged and merged in multiple small PRs.

---

Technical Backlog Management

Technical debt, infrastructure improvements, and developer experience work compete with product features for sprint capacity. Handle this explicitly:

## Backlog Categories

### Product Backlog (P1-P4 priority)
- Feature requests from stakeholders
- User-reported bugs (P1 = blocking, P4 = cosmetic)
- UX improvements

### Technical Backlog (separate swim lane)
- Tech debt items (from debt registry)
- Infrastructure upgrades
- Developer tooling improvements
- Performance optimizations
- Security patches (P0 = drop everything)

### Sprint Allocation Policy
- 80% capacity: Product backlog items
- 20% capacity: Technical backlog items (protected — not optional)
- Security patches: inserted into sprint immediately, regardless of allocation

---

Engineering Metrics That Matter

Not all metrics improve team performance. Some create perverse incentives.

Good metrics:

• Cycle time: Time from "in progress" to "deployed to production" — measures flow efficiency
• Deployment frequency: How often you deploy to production — measures delivery capability
• Change failure rate: % of deployments that cause incidents — measures quality
• MTTR (Mean Time to Recovery): How fast you recover from incidents — measures resilience

These are the DORA metrics (Google's DevOps Research and Assessment). Elite teams deploy multiple times per day, have < 1 hour change failure recovery time, and < 15% change failure rate.

Metrics to avoid:

• Lines of code (rewards bloat)
• Number of commits (rewards noise)
• Story points velocity as a performance measure (games the estimation)
• Code coverage as a target (encourages testing the wrong things)

-- Cycle time query — time from ticket "in progress" to "deployed"
SELECT
  ticket_id,
  started_at,
  deployed_at,
  EXTRACT(EPOCH FROM (deployed_at - started_at)) / 3600 AS cycle_hours
FROM tickets
WHERE deployed_at IS NOT NULL
  AND started_at >= NOW() - INTERVAL '90 days'
ORDER BY cycle_hours DESC;

---

Remote-First Engineering Process

Most engineering teams are now partially or fully remote. Process adjustments:

What changes:

• Standups become async (Slack/Loom updates, not video calls)
• All decisions are documented in writing (Notion, Confluence)
• Code review becomes primary communication channel for technical decisions
• Over-communication is a virtue — default to sharing context

What doesn't change:

• Sprint ceremonies benefit from video for complex discussions
• Retrospectives need video for emotional nuance
• Pair programming works over video (VS Code Live Share is excellent)
• Team social time should be protected, not eliminated

---

Common Process Failures

Standups as status meetings. Standups are about coordination, not reporting. The question isn't "what did you do yesterday" — it's "what coordination does the team need today?"

Sprints without sprint goals. "Ship 12 tickets" is not a sprint goal. "Enable users to invite team members and collaborate on projects" is a sprint goal. Goals create coherence; ticket lists don't.

Retrospectives without follow-through. If retrospective action items don't get done, engineers stop participating honestly. One action item per retro, assigned to a specific person, tracked in the backlog.

Estimation as commitment. Estimates are guesses, not promises. If engineering is held accountable to estimates as deadlines, the estimates will become inflated "safe" estimates that no longer reflect reality.

---

Process Consulting Costs

---

Working With Viprasol

We embed with engineering teams to improve delivery processes — from sprint structure through code review culture, technical backlog management, and DORA metric improvement.

→ Engineering process review →
→ IT Consulting Services →
→ Hire Dedicated Developers →

---

See Also

• IT Consulting Services
• Software Development Outsourcing
• Hire Dedicated Developers
• Startup CTO Responsibilities

---

Sources

• Agile Manifesto (2001)
• DORA State of DevOps Report 2024
• Ron Jeffries — The Dark Scrum
• Will Larson — An Elegant Puzzle: Systems of Engineering Management