MSF Agile at a Glance



I like to be able to scan process methodologies so I create skeletal views that let me quickly see the key activities, artifacts, principles, and practices of a methodology. 

MSF for Agile Software Development is a scenario-driven, context-based, agile software development process.  

Here’s are notes on MSF Agile circa 2005, which might be somewhat dated, but at least give me a quick lens into the main ideas:


  • Partner with customers
  • Foster open communications
  • Work toward a shared vision
  • Quality is everyone’s job every day
  • Stay agile, adapt to change
  • Make deployment a habit
  • Flow of value


  • Quality Is Defined By Customer
  • Pride of Workmanship
  • Team of Peers
  • Frequent Delivery
  • Willingness to Learn
  • Get Specific Early
  • Qualities of Service
  • Citizenship


  • Capture Project Vision
  • Create a Quality of Service Requirement
  • Create a Scenario
  • Guide Project
  • Plan an Iteration
    Guide Iteration
  • Create a Solution Architecture
  • Build a Product
  • Fix a Bug
  • Implement a Development Task
  • Close a Bug
  • Test a Quality of Service Requirement
  • Test a Scenario
  • Release a Product

Activities By Workstream

Capture Project Vision

  • Write Vision Statement
  • Define Personas
  • Refine Personas

Create a Quality of Service Requirement

  • Brainstorm quality of Service Requirements
  • Develop Lifestyle Snapshot
  • Prioritize Quality of Service Requirements List
  • Write Quality of Service Requirements
  • Identify Security Objectives

Create a Scenario

  • Brainstorm Scenarios
  • Develop Lifestyle Snapshot
  • Prioritize Scenario List
  • Write Scenario Description
  • Storyboard a Scenario

Guide Project

  • Review Objectives
  • Assess Progress
  • Evaluate Test Metric Thresholds
  • Triage Bugs
  • Identify Risk

Plan an Iteration

  • Determine Iteration Length
  • Estimate Scenario
  • Estimate Quality of Service Requirements
  • Schedule Scenario
  • Schedule Quality of Service Requirement
  • Schedule bug Fixing Allotment
  • Divide Scenarios into Tasks
  • Divide Quality of Service Requirements into Tasks

Guide Iteration

  • Monitor Iteration
  • Mitigate a Risk
  • Conduct Retrospectives

Create a Solution Architecture

  • Partition the System
  • Determine Interfaces
  • Develop Threat Model
  • Develop Performance Model
  • Create Architectural Prototype
  • Create Infrastructure Architecture

Build a Product

  • Start a Build
  • Verify a Build
  • Fix a Build
  • Accept Build

Fix a Bug

  • Reproduce the Bug
  • Locate the Cause of a Bug
  • Reassign a Bug
  • Decide on a Bug Fix Strategy
  • Code the Fix for a Bug
  • Create or Update a Unit Test
  • Perform a Unit Test
  • Refactor Code; Review Code

Implement a Development Task

  • Cost a Development Task
  • Create or Update a Unit Test
  • Write Code for a Development Task
  • Perform Code Analysis
  • Perform a Unit Test
  • Refactor Code
  • Review Code
  • Integrate Code Changes

Close a Bug

  • Verify a Fix
  • Close the Bug

Test a Quality of Service Requirement

  • Define Test Approach
  • Write Performance Tests
  • Write Security Tests
  • Write Stress Tests
  • Write Load Tests
  • Select and Run a Test Case
  • Open a Bug
  • Conduct Exploratory Testing

Test a Scenario

  • Define Test Approach
  • Write Validation Tests
  • Select and Run a Test Case
  • Open a Bug
  • Conduct Exploratory Testing

Release a Product

  • Execute a Release Plan
  • Validate a Release
  • Create Release Notes
  • Deploy the Product

Artifacts (Work Products)

  • Vision Statement
  • System Architecture (See DSI and Whitehorse)
  • Test Plan (see Context-Driven Testing)
  • Personas
  • Scenarios
  • Storyboards
  • Development Tasks
  • Interface Models
  • Architectural Prototypes
  • Unit Tests
  • Classes
  • Change Sets
  • Check In Notes
  • Test Cases
  • Bug Reports


  • Requirements
  • Planning
  • Architecture
  • Development
  • Test

Who Does What

Business Analyst

  • Capture Project Vision
  • Create a Quality of Service Requirement
  • Create a Scenario

Project Manager

  • Guide Project
  • Plan an Iteration
  • Guide Iteration


  • Create a Solution Architecture


  • Build a Product
  • Fix a Bug
  • Implement a Development Task


  • Close a Bug
  • Test a Quality of Service Requirement
  • Test a Scenario

Release Manager

  • Release a Product

Cycles and Iterations

  • Product definition, development, and testing occur in overlapping iterations resulting in incremental completion of the project.
  • Different iterations have different focus as the project approaches release.
  • Small iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans.
  • Each iteration should result in a stable portion of the overall system.


Iteration 0

  • Project Setup
  • Plan

Iteration 1

  • Plan
  • Develop and test
  • Feedback

Repeat as needed

  • Plan
  • Develop and test
  • Feedback

Iteration N

  • Develop and test
  • Release product

Team Model

Advocacy Groups

  • Architecture.
  • Development
  • Product Management
  • Program Management
  • Release Management
  • Test
  • User Experience

Who Advocates What

  • Architecture – advocates for the System in the Large.
  • Development – advocates for the Technical Solution.
  • Product Management – advocates for the Customer Business.
  • Program Management – advocates for Solution Delivery.
  • Release Management – advocates for the smooth delivery and deployment of the solution into the appropriate infrastructure.
  • Test – advocates for Solution Quality from the Customer Perspective.
  • User Experience – advocates for the most effective solution in the eyes of the intended users
Team Principles
  • Team of Peers.  A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
  • Advocacy for All Key Constituencies.  Advocacy for all key constituencies who must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
  • Stretch to Fit.  Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.


Concerns the control of time and money relative to the flow of value:

  • Are we doing the right thing?
  • Can we do it within time and budget?
  • Are we ready to integrate?
  • Are we ready to deploy?
  • Are we realizing the value?

Additional Resources

You Might Also Like

10 Ways to Make Agile Design More Effective
40 Hour Work Week
Agile Practices at a Glance
Don’t Let the Big Get in the Way of the Small
Don’t Push Agile, Pull It
Extreme Programming at a Glance
How To Drive Digital Transformation the Agile Way
Kanban for High-Performance Teams
Scrum at a Glance
The 4 Circles of Extreme Programming
Waterfall to Agile
What is Agile?


Please enter your comment!
Please enter your name here