Envisioning Tasks in MSF Agile

Now that you know your way around Visual Studio Team System, let’s take a look at how to perform certain envisioning tasks within Visual Studio Team System. As you might have noticed, Visual Studio Team System provides you with some of the document templates you will need to complete envisioning activities, specifically, a document template that allows you to capture the vision, personas, scenarios, and quality of service requirements.

Note 

You don’t have to create a new Team Project to get the document templates; you can download them from Microsoft ( www.microsoft.com/msf) or simply take a copy of the documents that reside in a newly created team project and store them in a safe place to be used during this phase of the project without the need for Visual Studio Team System.

Writing the Vision Statement

Let’s start with the writing of the Vision document. If you have already created a Team Project, you can access this document from the Requirements subdirectory of the Documents section in Team Explorer. Alternatively, you can access this document directly from the project portal in the Requirements document store. What is really nice about this document is that instructions on how to fill it out are inside starting with a section called “How To Use This Template.” The document is broken down into a few sections. In the “Background” section of the document, you will focus on the needs of the organization sponsoring the project. Here you will try to articulate the current state of the organization and your understanding of its future. This section should include a brief history of the business in relation to the project, the challenges the business faces that relate to the project, and the dependencies this project will have on other projects or vice versa. The template even provides an example of what the Background section could look like with a fictional AdventureWorks project.

The next section of the document is called “Driving Factors.” This section expresses all of the major requirements for the project in addition to the constraints such as timelines and budget that will guide scope decisions.

The final section is called “Vision Statement.” Your vision statement should be short and to the point and attempt to paint a picture of what life will be like when the project is complete. The default vision document provided for you gives you with plenty of guidance and examples in this area.

Identifying Personas

As we’ve already mentioned, Personas are representations of the users of your software. MSF provides you with a document you can use to capture persona information called Persona.doc, which is in the Requirements SharePoint document library for your project. You will likely fill out one of these documents for each user type you expect to use your program. The first step, however, is to identify those users. As with capturing the project vision, this job typically falls on the shoulders of the team member playing the role of the business analyst. This job starts by trying to get an understanding of all of the different roles users will play while using the software. A persona document will be created for each of the roles. Each document goes into extensive detail by establishing goals, skills, abilities, knowledge, motives, and concerns for the typical person who plays each role. The persona document also details the usage pattern of the persona with your system that details how often the persona will interact with the system and to what extent. This model is greatly improved over a traditional actor-use case model that you might find on projects that follow the Unified Process methodology.

Determining Iteration Length

As a project manager, you might also attempt to set the durations of iterations on your project. At this point in the project, this will be only a guess used to provide perspective on the entire project. During the planning phase of a project, you will again reaffirm these estimates after your team has more details on the requirements of the software, which will drive more specific estimates and hence a more accurate iteration plan. At this point, you will create an iteration using a common sense approach. You might start by saying “I think we’ll need two 1-week iterations for gathering requirements and creating an architecture for the software.” You might then take a look at the end of the project and say, “History suggests we’re going to need almost two months to stabilize and deploy the software; let’s do that over four 2-week iterations.” After you set some of the initial iterations and some of the iterations that have to happen at the end, you’re left with the available construction time, which you can also break into reasonable time blocks. Your initial iteration estimations might look similar to Figure 3-8.

Figure 3-8: The results of iteration length planning