It has been five years since I joined Microsoft and started writing MSF. There are a couple of milestones that this anniversary brings that I would like to share with you. First, the MSF book is not published and you have a right to ask why. Second, the robotics team that I have been mentoring (all 11-13 year olds) won the NC State championship and will advance to the National one. All of these kids can program extremely well as they have been working on building and programming robots for three years straight. Third, I continue to see the same negative patterns in (recovery) projects and I have been wondering if there is a way to process some of these patterns out of existence.

Some of you may not be aware that I have been working with two robotics team, one younger and one older. As I was working with the older Robotics team (high school kids), I happened to see a problem that I frequently encounter on projects. We were trying to test the robot in a museum on a simulated ice floor. The code for the drive control system was being finished on the way to the museum which is similar to the way many adult projects are done. When we got to the museum, we couldn't download the code to the robot.

Now, it turns out that we had fried the drive controller by static electricity from the simulated ice floor so it didn't matter. But as I thought about the current project that I was working on, it occurred to me that it had the same problem. One fellow who was working on it was out for the week and had no realistic backup. He had changed some of the code and it wasn't working as intended. We hadn't found the problem until he had left for vacation. It was an honest mistake (and one where he will have a pair from now on). But the delay cost the project.

A stitch in time saves nine.

I look back on the original manuscript for the MSF book and I don't like it. The whole introduction about second generation agile processes needs to go. My thinking was clearly flawed (some would say on several aspects :-)).

We are rewriting a piece of one project that I am working on because we now know more about this area than we originally did. The area works but it isn't elegant and certain bugs are unfixable. We have learned by doing once and then doing right.

But sometimes, like good wines, things have to age.

What has this got to do with programming kids, the MSF book, my projects, and my anniversary? I suspect that all have been influenced by stitches in time and aging. But sorting out the things to age and the things to rush is always the hard part. I suspect that we should always strive to do something and then evaluate how well we did. That is far better than waiting until we get it 100% right.

Short Description

Scenarios are used to define the services that the software will provide to the user.  A scenario can be thought of as a path through the system and can be represented by use cases or collections of user stories.  Most of the scenarios for a system are written at the start of the project to help scope the work and identify the most important features or services of the system to be developed.  It is not uncommon, however, that new scenarios are identified or existing ones modified or deleted as the development of the system proceeds and iterations are completed and previewed by users.

Scenarios are user and product, not technology focused.  They are written in the language of the user and can be as short as a couple of sentences or as long as a few pages. Each scenario must stand on its own.  Scenarios can be written as a collection of steps that the user performs when interacting with the system and the resulting services that the system performs for the user.  When writing scenarios, the prerequisites for a given scenario should be spelled out ahead of time.  When writing a scenario, it is often best to name the scenario as something that either describes the intended result or the problem the user wants to solve.

Workproduct Inputs

• Vision statement or document
• Access to domain expert or end users of the proposed system
• Personas of expected users of the system

Workproduct Outputs

• A description of a path through the system to be developed
• An initial understanding of what the end user for that path expects or needs from the system

Checklist(s)

Writing Good Scenarios, items to consider

Size and number of scenarios

Yesterday, we released brand new versions of MSF for Agile Software Development and MSF for CMMI Process Improvement. These new versions create the first commercial agile and CMMI-based software development processes with support for database unit tests and refactoring. The release of these processes coincided with the release of our tooling support for these practices, Visual Studio Team Edition for Database Professionals. These new versions also contain several bug fixes and clarifications.

If you are using the Visual Studio Team Foundation Server, here are the instructions to update the MSF versions.

Instructions

If you want to view the guidance

1.    Download and extract the contents of the zip file to your local machine. (select Use folder names).

2.    In the extracted files, review the Readme.

3.    To view the content, open \Process Guidance\ProcessGuidance.html.

If you want to update the guidance in a process template

1.    Download and extract the contents of the zip file to your local machine.

2.    If required, customize process guidance using instructions available at http://msdn2.microsoft.com/en-us/library/aa730855(VS.80).aspx.

3.    Download the process template you want to update guidance on from your TFS server to your local machine.

4.    Replace “Windows SharePoint Services” folder in the process template you downloaded from TFS with the one you obtained from the web download.

5.    Upload the updated process template back to TFS.

6.    When you create a new project using this updated process template, the portal will show the updated guidance.

If you want to replace the guidance already on the SharePoint server

1.    Download and extract the contents of the zip file to your local machine.

2.    Go to the home page of your project portal.

3.    Click Documents and Lists, and then "Document Libraries" in the left menu.

4.    Replace all files and folders in the following Document Libraries on SharePoint site from their corresponding folders under "Windows SharePoint Services" folder in the process guidance you downloaded.

1.    Project Management

2.    Requirements

3.    Security

4.    Test

5.    For the "Process Guidance" Document Library, replace the following files and folders with the new content

1.    Folder – Supporting Files along with all the subfolders and files

There are newer versions (August 2006) of the MSF process guidance available for download. There has been a few issues with unzipping the CMMI process guidance. Take a look at Rob's post on this subject. Remember that if you want to replace the guidance on an existing project, you need to checkout the existing guidance from the project portal.

We will be moving the MSFWinBuild site from GotDotNet to CodePlex in the near future. When we move the site, we will also make the process guidance source available on it as we currently do on MSDN. We will update them with major releases simultaneously. However, we are considering smaller releases and community feedback through this forum.

I get many questions about writing scenarios, but writing scenarios in general is a four-step process: identifying the scenarios, prioritizing & estimating scenarios, authoring scenario narratives, and decomposing scenarios into tasks. This blog entry looks at the first of these categories of questions, identifying scenarios. We start by identifying our scenarios to ensure we create scenarios in an agile way. As we traverse all four parts of this subject, you will see how agile scenarios can be.

There are actually many ways to brainstorm scenarios. A simple way is to gather your customers in a room and brainstorm with them. However, there is a more methodical approach, which starts by having the customers define the goals of the system similar to the way that we define these goals in use case modeling [Miller 2001].

A scenario is a single path of customer execution through the system. We ideally want to create very thin paths that we can augment as we go through each iteration. There are the “sunny day” scenarios, which provide the shortest paths to success. For example, in an online DVD rental system, the goals might be as shown in Figure 1.

Figure 1: The Scenario List

Each of these is potentially a scenario of the system. There are also exception scenarios where we look at things that affect these success scenarios. For example, we might have the maximum number of videos rented by a customer, and thus we might prohibit them from renting any more before returning videos.

When we are brainstorming scenarios, we don’t actually write the scenario narratives. Instead, we only use the names of the scenarios as placeholders to remind us that there is functionality to implement. We call these names scenario entries in the scenario list. A scenario entry is usually of the form, “goal : path” and might contain some notes on the differentiating factors or the thing that differentiates this scenario from the others. Usually the differentiating factors are clear from just reading the scenario name.

In the course of prioritizing & estimating our scenarios (described in Part 2), we may find that some of our scenarios are too big for a single iteration. To deal with this, we split these scenarios into smaller scenarios. These new scenarios should always provide customer value. For example, we might find that the sunny day scenario for “Rent DVD” is too big. In looking at this scenario, we can divide it into several smaller, customer-valued scenarios (as shown in Figure 2).

Figure 2: The brainstormed scenario list

Perhaps a simpler scenario than the “Rent DVD” scenario is to rent a single DVD. In this scenario, we search for a DVD by name and add it to our cart. Subsequent scenarios might allow renting multiple DVDs, add search options, and increment the number of DVDs rented with the appropriate new billing.

Activity: Divide Scenarios into Tasks

Project Manager

Plan an Iteration

Task

Participating Roles Responsible: Project Manager Consult: Architect Developer Tester

Overview

Entry Criteria

Dependencies:

• The scheduled scenario description is written and storyboarded if necessary.

Sub-Activities

1	Gather the Team	Gather the architects, developers, and testers who will be working on or impacted by this scenario. The project manager facilitates this brief meeting or email discussion and records the tasks.
2	Identify Architecture and Development Tasks	Begin where the scenario differs from previously implemented scenarios and follow the control path through the system. Consider user visible features, changes to the underlying infrastructure or data structures and items that have architectural impact. Identify how system components are affected when implementing the planned scenario. Ensure that the architecture will be able to handle the scenario. If architectural changes are necessary, create the roadmap and tasks for refactoring the architecture to the new state. Split the scenario if necessary.  Create a new development task for each major area of the system impacted by the scenario. For each task, describe the new or changed functionality. Keep the tasks broad enough to allow design to emerge but focused enough that a single person could complete them in one to three days. Group low level changes that are logically related into higher level tasks. Further divide high level changes and additions into lower level tasks if they are broad. Review the set of tasks to ensure that they adequately address the scenario.
3	Choose Architecture and Development Tasks	Architects and developers choose their own tasks. Check to make sure all architecture and development tasks are chosen.
4	Reassign Scenario to a Developer	Reassign the scenario to one of the developers who owns development tasks for that scenario. This developer’s job is to test the end-to-end integration of the development tasks.
5	Create Test Tasks	Update the test approach document for the iteration, filling in the test data and other sections. Create a set of tasks to create the necessary test cases to achieve the goal of the iteration. Determine which tests can be automated and added to the iteration tests. The iteration tests run after the build verification tests.
6	Choose the Test Tasks	Allow the testers to choose their test tasks. Check to make sure all test tasks are chosen.

Exit Criteria

	The initial iteration plan contains tasks describing all work necessary to fulfill all the scenarios scheduled for the iteration.
	All tasks created during the brief meeting are chosen.

The agile software development community is at a crossroads. On one hand, we have been told to use some very simple techniques to create customer value quickly and they have worked! Interact with your customer, use the simplest thing that might possibly work, deliver value. This is all good. The processes that we have used to come to this point have names like SCRUM and XP (version 1). These processes are terrific.

However, if you have been to one of agile conferences recently (or even one of the major software development conferences), you are aware that there is an ever growing array of techniques available to agile developers to incorporate things that were missing from these agile processes such as the use of testers to test. The agile community has not stood still; it is evolving.

In fact, if you read Kent's latest XP Explained book (the green and white book), you get a slightly different view of XP than you do if you read his earlier white book. In the chapter called "The Whole XP Team" (chapter 10), he talks about the role of the Tester, Interaction Designer, and Architect among others (don't just read the first section of the chapter unless you want to get the wrong idea of what he is trying to say). Whoa! What kind of agile blasphemy is this?

The truth is, the agile community has been moving toward perhaps a more centrist (pardon the pun) position for years. Those who are involved in the community are acutely aware that architecture is required especially for larger projects. Not Big Design Up Front (BDUF) architecture but shadow architecture, one that leads and trails the actual inner workings of the project code. The fact that each role often worked as disconnected units had to be broken. For this, we needed to go to the extremes. Kent calls the early versions of XP etudes or lessons (hard lessons) in building functional teams.

The "new" XP is a second generation agile software development process. So is our own MSF for Agile Software Development (a lot of the patterns within it are based on XP). Both processes have techniques for allowing testers to test the software and architects to help with large scale refactorings. Both are directly driven by customers (more on this in a future blog) and this is a critical success factor. They both are also a little more complex than the first generation processes.

The number of people using first generation agile processes is increasing. It is also true that many companies are using a "Chinese menu" (to quote Uncle Bob Martin) approach to creating their own second generation agile processes. Some would argue about the "agileness" of these processes. The truth is, it is all about delivery. If you deliver as rapidly as possible, don't let anyone tell you to stop. It is when things are breaking down or your competition is outrunning you that you have problems.

It isn't surprising to me that many have grown comfortable with the first generation agile processes. If these work for you, continue. What is surprising is the number of people who are advocating these processes that think that a greater number of roles cannot participate and maintain the agility. The agile world is changing. Embrace change.

I was fortunate enough to attend TechEd Europe this summer and attend (instead of presenting) a session on MSF presented by Rafal Lukawiecki. Rafal described the changes that we have made between the old (3.0) and new versions of this framework for building processes. His session was very entertaining and won ”Best in Show”.

One of his many interesting assertions was, “Integration is a marketing term for ‘we ain’t gonna ship on time.’” It’s always interesting to hear a European use colloquial American English as part of their presentation. He was, of course, referring to the waterfall approach where components are created in isolation and brought together to create the contorted (improperly integrated), old dog. This is, as Rafal asserted, an unnatural act, as nature grows the dog from a baby puppy instead. The logical conclusion is that iterative development is the more natural way to build software.

There are many analogies that follow from this idea. However, I felt that it was time to turn this blog from overview topics like competition and project size to more detailed topics in MSF for Agile Software Development. Since integration is the topic of the day, I thought that this would be a great place to start.

Integration is not often discussed in most software development processes. This is a shame since the amount of effort involved can be trivial on many projects, and enormous on others. Some factors that increase the cost of integration include project size (large projects are costlier), embedded systems where the hardware is changing out from under them, and systems created by multiple teams or parties. But even if integration is easy on your project, it should not be taken lightly.

Here’s a question for the testers in the audience. How many times have you received what is supposed to be working functionality only to find that it doesn’t work at all? Hopefully, this is a rare occurrence but even if the answer is once, it is one too many times. I certainly don’t doubt the best intensions of the developers that gave you the system, but it may not have been anyone’s job to test that the integration produced the behavior of the scenario from end to end.

To ensure that this does not happen, we assign the scenario work item to a developer when it is scheduled for the current iteration in the iteration plan (known as the sprint backlog in Scrum). This developer is probably one of the developers with development tasks that need to be completed to implement the scenario. As soon as they can see the entire scenario working in an accepted build, they may now reassign the scenario to a tester. If an automated test case can be created to test the scenario, the automated test case is attached to the scenario. In this way, there is no confusion about whether the pieces of the scenario have been completely integrated.

Assignment to test is also a sign that the scenario (or quality of service requirement) is integrated and ready to be tested. The tester assigned the scenario lets the other testers who have test tasks for that scenario know that the new build is ready to be tested. Once all of the tests have run unblocked (and bugs created if necessary), the scenario can be closed.

One of the things that the Remaining Work report shows is whether this process is running smoothly. A widening gap in the Remaining Work report for scenarios indicates that either test is being overrun by new functionality or that too many tests are blocked. This should be an indication to the project manager that a bug allotment iteration may be needed.

Another area that the cost of integration influences is the length of the iterations. While two week iterations may be fine for small teams with minor integration costs, longer iterations may be needed for teams that incur higher integration costs. Six to eight week iterations are the norm for larger projects that may utilize teams of teams, or have larger scenarios.

All of this shows a philosophy that we have espoused all along. Understanding the dynamics of your project, including details such as integration, will help you become more efficient in building software. But these details are useless without a context-based, or configurable, software development process. MSF for Agile Software Development is such a process.