ALM with Scrum: A Practical Guide for .NET Teams

ALM Isn't Just Tools — It's a Discipline

Application Lifecycle Management (ALM) is the end-to-end discipline of managing software from conception to retirement. For .NET teams, ALM spans requirements gathering, architecture, development, testing, deployment, maintenance, and governance — all coordinated through a defined process.

Scrum provides the iterative framework. ALM provides the discipline. Together, they give .NET teams a repeatable path from idea to production — with visibility at every step.

This guide is based on 15+ years of delivering .NET projects with Scrum. It covers the full lifecycle, tooling choices (Azure DevOps, GitHub, Visual Studio), and the metrics that actually predict delivery success — not vanity metrics.

The ALM Framework: Five Phases, One Rhythm

ALM breaks software delivery into five interconnected phases that map directly to the Scrum cadence:

The key insight: ALM phases aren't sequential waterfalls. They run concurrently within each sprint. By the end of a sprint, you have working, tested, potentially shippable software — not just "code complete."

Phase 1: Requirements & Planning That Actually Works

The Product Backlog: More Than a List

A healthy product backlog is the foundation of effective ALM. For .NET teams, each backlog item should include:

• User story: "As a [role], I want [feature] so that [outcome]."
• Acceptance criteria: Specific, testable conditions that define "done." Use the Given/When/Then format for clarity.
• Technical notes: Architecture decisions, database schema changes, API contracts, NuGet package impacts.
• Estimate: Story points or ideal hours. We recommend story points based on complexity, effort, and uncertainty — not time.
• Dependencies: Other backlog items, external services, third-party APIs, or infrastructure changes this item depends on.

Sprint Planning: The Commitment Meeting

Sprint planning has two parts:

Part 1 — What: The Product Owner presents the highest-priority backlog items. The team asks clarifying questions and negotiates scope. Output: a sprint goal — a one-sentence summary of what the sprint delivers.

Part 2 — How: The team breaks each backlog item into tasks (typically 2-8 hours each). For .NET projects, tasks often include: database migration, API endpoint implementation, service layer, unit tests, integration tests, frontend component, code review, and documentation update.

Planning anti-patterns to avoid:

• Tasks like "Write code for feature X" — too vague. Break it down into specific deliverables.
• 100% capacity planning — leave 20-30% buffer for unplanned work, bugs, and collaboration.
• Ignoring technical debt — allocate at least one backlog item per sprint to refactoring or debt reduction.

Phase 2: Development — Where Code Meets Process

Branch Strategy for .NET Teams

We recommend a trunk-based development model with short-lived feature branches:

master (always deployable)
  └── feature/dotnet9-migration (1-3 days)
  └── feature/payment-plugin-pix (1-3 days)
  └── fix/checkout-null-reference (hours)

Rules:

• Branch from latest master, merge back within 3 days max.
• One PR per feature or bug. Small PRs get reviewed faster and merged sooner.
• Each PR must pass CI (build + tests) before review.
• Require at least one approval. All review comments must be addressed before merge.
• Squash-merge to keep master history clean.

Code Review Standards for .NET

Code reviews should check for:

• Correctness: Does the code implement the acceptance criteria? Are edge cases handled?
• Security: No hard-coded secrets. Input validation. SQL injection prevention. Proper auth checks on endpoints.
• Performance: No N+1 queries. Async all the way down. Appropriate caching. Connection pooling.
• Testability: Logic is in injectable services, not static methods or controllers. Dependencies are abstracted behind interfaces.
• Convention: Follows project naming conventions, folder structure, and coding standards.

Daily Scrum: Not a Status Report

The daily scrum is a coordination meeting, not a micromanagement tool. Each team member answers: what did I complete yesterday, what will I complete today, and what's blocking me? If a blocker emerges, the Scrum Master resolves it — outside the daily scrum. The meeting should take 15 minutes, not 45.

Phase 3: Continuous Integration — Automate Everything

The CI Pipeline for .NET Projects

Every commit to a feature branch should trigger:

1. Restore: dotnet restore — resolves NuGet dependencies. Cache packages for speed.
2. Build: dotnet build --configuration Release --no-restore — compile with optimizations. Treat warnings as errors.
3. Test: dotnet test --no-build --configuration Release — run all unit and integration tests. Fail the build on test failure.
4. Analyze: Run StyleCop, SonarQube, or the .NET analyzers. Block merge if new warnings are introduced.
5. Package: For libraries: dotnet pack. For applications: dotnet publish. For Docker: docker build.

Example: Azure DevOps YAML Pipeline

trigger:
  branches:
    include:
      - master
      - feature/*
      - fix/*

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    version: '9.x'

- script: dotnet restore
  displayName: 'Restore packages'

- script: dotnet build --configuration $(buildConfiguration) --no-restore
  displayName: 'Build solution'

- script: dotnet test --no-build --configuration $(buildConfiguration) --collect:"XPlat Code Coverage"
  displayName: 'Run tests'

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Build Verification Tests (BVT)

Beyond unit tests, include a small set of smoke tests that run as part of CI — verify that the application starts, the database connects, the main API endpoints return 200, and critical user journeys work. These catch environment and configuration issues that unit tests can't see.

Phase 4: Testing & Quality — Beyond "It Works on My Machine"

The .NET Testing Pyramid

Testing principle: Write tests at the lowest level that gives you confidence. Not every feature needs an E2E test — a well-tested service layer with integration tests for the database layer catches most bugs faster and more reliably than browser automation.

Sprint Review: Demo Working Software

The sprint review is a demonstration of working, tested software — not a slide deck. Show the features as they will appear to users. Collect feedback directly. Update the backlog based on what you learn. If a feature isn't demonstrable, it wasn't done.

Phase 5: Release & Operations — From Done to Deployed

Release Management for .NET

Releases should be boring — automated, predictable, and reversible. Here's the flow we use at SplatDev:

1. Version bump: Semantic versioning (MAJOR.MINOR.PATCH). Bump during the sprint as features land, not at release time.
2. Release branch: Cut from master with the version tag. Only hotfixes merge to release branches.
3. Staging deployment: Automated deployment to a staging environment that mirrors production. Run the regression suite.
4. Smoke test: Manual verification of critical paths in staging. Capture screenshot evidence.
5. Production deployment: Blue-green or canary deployment. Monitor error rates, response times, and business metrics for 30 minutes post-deploy.
6. Post-deploy verification: Confirm the deployment against the release checklist. Update the release notes.

Monitoring: Know Before Your Users Tell You

Production monitoring is part of ALM — you're not done when you deploy, you're done when you've confirmed the system is healthy. Key metrics for .NET applications:

• Application errors: Unhandled exceptions, 500 responses. Alert immediately.
• Response times: P50, P95, P99 latency per endpoint. Alert on degradation.
• Throughput: Requests per second. Alert on anomalies.
• Resource usage: CPU, memory, GC pauses, thread pool exhaustion. Watch for leaks.
• Business metrics: Orders placed, payments processed, sign-ups completed. These are your real health indicators.

Use Application Insights (Azure), Datadog, or Prometheus + Grafana for .NET monitoring. Log to a structured logging system (Serilog + Seq/Elasticsearch) — never debug from production console output.

Scrum Metrics That Actually Predict Success

Most Scrum metrics are vanity. Here are the ones that correlate with delivery outcomes:

Lead Time and Cycle Time

Lead time: Time from backlog item creation to deployment. Cycle time: Time from work start to deployment. Shorter is always better — it means smaller batches, faster feedback, and less work-in-progress. Target: cycle time under 5 days for most items.

Sprint Burndown (with caution)

Burndown charts show remaining work vs. time. A flat burndown for the first half of the sprint followed by a crash at the end means your team is finishing work late and not delivering incrementally. The ideal burndown is steady — work completes throughout the sprint, not just at the end.

Escaped Defects

Bugs found in production that should have been caught earlier. This is the single most important quality metric. If your escaped defect count isn't trending toward zero, your Definition of Done or your testing strategy is insufficient.

Deployment Frequency

How often you deploy to production. Elite performers deploy multiple times per day. For most .NET teams, deploying at least once per sprint is a good target. If you deploy less often, you're batching too much risk.

Sprint Retrospective: Feedback Loops That Actually Change Things

The retrospective is the most important Scrum ceremony — and the most frequently skipped. Run it every sprint. Ask three questions: what went well, what went poorly, what will we change next sprint? Then — critically — pick ONE action item and do it. Nothing kills retrospective value faster than discussing the same issues sprint after sprint with no change.

Tooling: The .NET ALM Stack

Azure DevOps (Recommended for Enterprise .NET Teams)

Azure DevOps provides an integrated ALM suite: Azure Boards (backlog management, sprint planning, boards), Azure Repos (Git hosting with branch policies), Azure Pipelines (CI/CD with first-class .NET support), Azure Test Plans (manual and exploratory testing), and Azure Artifacts (NuGet package hosting). For teams already on Azure, the integration is seamless.

GitHub + GitHub Actions (Recommended for Open-Source and Modern Teams)

GitHub provides Projects for backlog management, Issues for work tracking, Actions for CI/CD, and Packages for NuGet hosting. GitHub Advanced Security adds code scanning, secret scanning, and dependency review. For teams that don't need Azure Boards' depth, GitHub provides a simpler, more developer-focused experience.

Visual Studio + VS Code

Visual Studio Enterprise includes ALM features: architecture diagrams, IntelliTest (automated test generation), live dependency validation, and code clone detection. For teams that value these tools, the Enterprise license pays for itself in reduced debugging time.

Getting Started: A 30-Day ALM Implementation Plan

1. Week 1: Set up your toolchain — Azure DevOps or GitHub, CI pipeline, test framework. Define your Definition of Done.
2. Week 2: Populate the product backlog. Run your first sprint planning. Establish the Daily Scrum rhythm.
3. Week 3: Complete the first sprint. Demo working software. Run the retrospective. Measure your cycle time and escaped defects baseline.
4. Week 4: Deploy to production (or staging if policies require). Review metrics. Adjust the process based on the retrospective. Repeat.

The goal isn't perfect Scrum — it's a process that produces working software predictably and visibly. Start simple, measure everything, and improve incrementally.

How SplatDev Delivers with ALM + Scrum

We've been delivering .NET projects since 2009 — before Scrum was mainstream and before Azure DevOps existed. Our ALM consulting practice helps teams adopt the practices described in this guide: backlog management, sprint discipline, CI/CD pipeline setup, test automation, and release management.

We provide ALM consulting for .NET teams of any size — from a 3-person startup to a 50-person enterprise team. Our engagements typically include: process assessment, tooling setup, sprint coaching (we run 2-3 sprints alongside your team), and a transition to self-sufficiency.

Want to ship .NET software faster, with fewer bugs and less stress? Let's talk about your current process and where ALM + Scrum can make the biggest impact.

Get ALM Consulting

Or contact us: contact@splatdev.com