Scenario Frames


One of the best ways I’ve found to map out a problem space is to create what I call, “Scenario Frames.”  I call them scenario frames because they are an organizing frame of scenarios.   Simply put, they’re a set of one-liner stories or scenarios organized by categories.  The beauty of a scenario frame is that it can contain macro-level or micro-level scenarios and, because it’s a tickler list, it’s easy to traverse.

Why Scenario Frames
They’re perfect for framing the landscape.  You can use Scenario Frames to design products more effectively.  You can also use Scenario Frames to help you map out and chunk up value that you want to ship.  For example, you can use it for scenario-driven design.  You can also use your Scenario Frames to measure your success.  For example, you can use the scenarios for scenario-based testing.

Without scenario frames, it’s hard to scope.  It’s also hard to know when you’re done.   With a scenario frame, it’s easy to share the map across the team or stakeholders.  You can even use the scenario frame to measure you results, like a consumer reports.   Simply test customer success against the scenarios using your solutions.

Creating Scenario Frames
One way to create scenario frames is to collect your user stories and organize them into categories.    The resulting categories are effectively “Hot Spots.”  They’re a heat map of either opportunity or improving some sort of pain.

Example Scenario Frame
Here’s an example Scenario Frame we created for our patterns & practices Team Development with Team Foundation Server guide.  This particular Scenario Frame is for Source Control:


  • Accessing Version Control
  • Administration
  • Branch / Label / Merge
  • Check-ins and Check-in Policies
  • Checkout, Get, and Lock
  • Dependencies
  • Distributed / Remote Development
  • Migration
  • Project / Workspace Management
  • Shelving

Accessing Version Control       

  • Work offline, syncs changes when back online   
  • Automate a common version control task   
  • Use Team Foundation Version Control from a MSSCCI compatible client   
  • Use Team Foundation Version Control using third-party integration   
  • Create your own integration solution to access Team Foundation Version Control   
  • Use Team Foundation Power Tools to accomplish tasks impossible from the UI   
  • Use the version control command line interface   


  • Remove a developer from the project   
  • Add a developer to the project   
  • Give a developer access to a portion of the source tree   
  • Modify source control permissions on branches   
  • Move the source tree to another server   

Branch / Label / Merge       

  • Apply a label to a set of files and folders   
  • Create a branch to support a release   
  • Use a branch to maintain a release   
  • Create a branch to support isolated feature development   
  • Create a branch to isolate external dependencies   
  • Retire an old release   
  • Perform a forward integration merge from parent branch to child branch   
  • Perform a reverse integration merge from child branch to parent branch   
  • Execute a merge across branches   
  • Resolve merge conflicts   
  • Perform a baseless merge

Check-ins and Check-in Policies       

  • Use check-in policies to enforce coding standards prior to check-in   
  • Use check-in policies to enforce unit tests at check-in    Dev   
  • Create a custom check-in policy   
  • Override a check-in policy   
  • Receive notification of a check-in policy override   
  • Check-in a change set   
  • Undo a previous check-in you made   
  • Undo another developer’s check-in   
  • Resolve a conflict at check-in   
  • Automatic conflict resolution fails to resolve a check-in   
  • Avoid conflicts with other developers   

Checkout, Get, and Lock       

  • Get the latest version of the source tree   
  • Get the latest version of a sub-set of the source tree   
  • Check-out a file for editing   
  • You are making major changes to a file and need to lock out other developers   
  • You need to reorganize your source tree and must lock it down until done   
  • Lockdown before shipping your application


  • Manage web service dependencies   
  • Manage database dependencies   
  • Use project references to reference dependencies in the same solution   
  • Use file references to reference dependencies in another solution

Distributed / Remote Development       

  • Remote developers access TFS over the internet – no proxy   
  • Remote office accesses TFS over the internet – using proxy   
  • Partner accesses TFS over the internet   
  • Untrusted users access TFS over the internet   
  • Remote office sets up TFS Version Control Proxy   
  • Remote office optimizes TFS Version Control Proxy performance


  • Migrate source from VSS to TFS   
  • Migrate source from ClearCase to TFS   
  • Migrate source from PVCS to TFS    Admin   
  • Migrate source from StarTeam to TFS   
  • Migrate source from PerForce to TFS   
  • Migrate source from an open source solution (GNU-RCS, CS-RCS, GNU, CVS, SVN) to TFS   
  • Create a custom migration solution with TFS Migration and Synchronization Toolkit to migrate source from a source control system that does not yet have a migration solution
  • Move from one TFS server to another

Project / Workspace Management       

  • Set up a new project with MSF Agile or MSF CMMI   
  • Set up a new project with customized process guidance   
  • Create a new project based on existing code   
  • Choose one team project vs. multiple team projects   
  • Define workspace mappings   
  • Create a local workspace to unshelve another developers changes   
  • Create a local workspace to look at a bug in isolation   
  • Create a local workspace to isolate high risk code changes   
  • Structure your source control tree to support branching and merging


  • Shelve a changeset to backup pending changes to focus on higher priority work or to back-up work at the end of the day   
  • Shelve a changeset to share pending changes for a buddy test, to get a code review, or to hand off partially completed work   
  • Unshelve your own changeset to return to past work   
  • Unshelve another developer’s changeset to perform a buddy test, code review, or to take over partially completed work

My Related Posts

Photo by mugley.


  1. I have been using scenario-building for myself for years and your post really helped me hone how I do it. Thank you so much. I will mention this post when speaking at iabc on communicating to collaborate

  2. @ Kare

    Scenarios are definitely the way to go, especially for shared understanding / collaboration. They’ve served me well.

    Great to hear – thank you!

Comments are closed.