Creating an Initial Iteration Plan

An initial iteration plan breaks down your project into fixed time durations and tentatively schedules features for each iteration. The iterations that you can specify in your project are simply labels and have no relation to any particular block of time or duration. For this reason, many organizations change their iteration-naming conventions to include the data ranges the iteration covers. For example, instead of having Iteration 1, organizations would change the name of the iteration to “Iteration1 – Dec18–Dec29”. Even when doing this, Visual Studio Team System will still not understand that all requirements assigned to Iteration 1 – Dec18– Dec29 must be performed during that block of time in the calendar. As a project manager, you are likely experienced in using Office Project to aid in project scheduling, and with Visual Studio Team System, you use can use Office Project the way you might have before.

Determining Iteration Length

Before you can begin adding iterations into Office Project, you must determine the duration of each of the iterations. This process is usually best performed with a calendar in front of you and will start with the day you will need to deliver. Most projects have some targeted delivery date in mind, which is captured in the project charter document. The project charter also details the constraints with regard to costs and resources. With these constraints in mind, you should be able to determine the size of your team and how long the project will take from beginning to end. For example, suppose that you had a budget for staff of $100,000 for your project. Let’s also assume that the average cost of a team member is $50 per hour. This would indicate that you have about 2000 hours to work with. If you determined that you will need four additional team members, one to act as the business analyst and tester, two developers (who will share the role of Architect), and another full-time employee to act as tester and release manager, this would mean that you have five full-time people employed to deliver the project. Given 5 people (each with a cost of $50 for 8 hours a day) and $100,000 budgeted for effort (which does not include hardware, software, contractors, or any other cost not associated with salary), you will need about 10 weeks of time.

Working backward on a calendar from your required delivery date will give you the date your project should begin. From this point, you can now determine how to specify your iterations. Let’s start at both ends of the project. You will make the assumption that it will take at least one week to get the project environment ready for the team, finalize requirements, and refine estimates and assumptions. You might also assume that you will need a week at the end of the project dedicated for bug fixing and release-to-production work. This leaves you 8 weeks of time to spend developing the solution. Based on conversations with your customer, you might also want to dedicate a week to focus on setting requirements regarding the user interface and final architecture. You are told by your developers, however, that this activity can be performed in the same week that the development environment is getting finalized and ready. How you decide to break up the remaining 8 weeks of work will truly depend on the cycles you and your team are accustomed to. Some organizations like to have development iterations set at three weeks, others at one week. In this case, 8 seems like a good number to divide into 4 equal iterations of 2 weeks each. Thus you decide that your project will have six iterations; the first iteration dedicated to requirement finalization and development environment construction, four development iterations, and one stabilization-and-transition-to-production iteration. At this point, you may even want to specify customer release drops. It is normal to have Alpha, Beta, and Release Candidate releases prior to your final release. Each of these will be formalized releases of your software to your customers for the purpose of gathering feedback and discovering defects. Each successive release will obviously be more mature than the previous. An Alpha release typically releases only some of the features of your application, usually the highest-priority features or features that must be developed early in the project because they are architecturally similar to other features in the application. Each subsequent release adds new features while fixing or modifying existing features based on user and testing feedback. The Release Candidate feature typically represents a feature complete version of your software, implementing every committed feature. Any subsequent work done to the application after the Release Candidate is bug fixes or changes to deployment, as shown in Figure 4-6.

Figure 4-6: Example iteration breakdown

It is extremely important to communicate the release plan to your customers so they can plan to test each release. These major releases are usually provided to as wide a customer base as possible to ensure the most scenarios tested. Because these major releases are quite important in the software development life cycle, they are equally as important as interim releases of the product produced daily and weekly to a smaller group of testers and customers. Interim builds, commonly known as daily or weekly builds, represent an important quality practice your team can practice and will be discussed in great length in Chapter 5, “Monitoring and Controlling Projects Execution.”

Buffering Estimates

Up to this point, we have discussed only about how to aggregate estimates from your team, but we have not talked about buffers. A buffer is a length of time and money set aside for tasks that take longer or cost more money to complete. If this is the case, then how much buffer is enough? Many organizations look to previous projects to determine an overall percentage of time and money that should be reserved for each project to compensate for unplanned events or underestimated work. Buffers are typically a reflection of certainty. That is, work that your team is less certain of performing will increase the amount of buffer they include in their estimates. Most organizations do not explicitly measure a certainty factor when it comes to estimation; however, you should consider doing so because it will allow you to determine a better estimate for the buffer for your project. Buffers are usually applied against a cycle in a project. For example, some buffers are held at the end of a project to compensate for overall project slippage. Some buffers are worked into each iteration based on the certainty of the work being performed in that iteration. How you decide to integrate buffers into your process will be greatly dependent on how complex buffer management and tracking is because the more elaborate and accurate the method of managing buffers, the more elaborate your tracking system must be.

The details of the various ways that buffers can be calculated and integrated into your estimating practices are beyond the scope of this book. This book’s only advice is that you do consider buffers in your planning considerations, even if, for example, you simply call for a 10 percent contingency for your entire project. For some great references on buffers and the theory of constraints as it applies to software engineering, you should read David Anderson’s book, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Prentice Hall PTR, 2003).

One of the best methods of creating an initial release plan is to use the Office Project integration features of Visual Studio Team System. To use Office Project to create an initial release plan, perform the following steps:

1. Launch Office Project and begin working with a new project plan.

2. In Office Project, select Team | Choose Team Project to display a dialog box that will allow you to specify the Team Project to connect to. Specify your computer running Team Foundation Server and the Team Project and then click OK.

3. Choose Get Work Items from the Team menu in Office Project to display the Get Work Items dialog box. From the Saved query drop-down list, choose All Scenarios, and then click Find. Here, you are instructing Office Project to import all of the Scenario work items you specified in your project so that you can schedule them into iterations. After the list of work items is retrieved from the server, click OK to add these work items to Office Project.

   Note 

   Even though the work items you just specified were scenarios, they have been added to Office Project as tasks. Notice the updated view in Office Project and how work item data is available, such as Work Item ID, Work Item Type, Area Path, and Iteration Path. In fact, entire new views called Team System Gantt and Visual Studio Team Task Sheet were created in Office Project specifically for Visual Studio Team System integration. You can switch between these views by selecting them in the View menu.

4. Insert a new row at the top of Office Project and provide the name of one of your iterations as the Title. Do not worry about setting the duration or start/end dates for the task at this time. Continue this process for every iteration on your project until you have entered a new task for every iteration.

5. By default, when you add a new task after you have linked to work items on your Team Project, these new tasks will be marked as new work items, and Office Project will attempt to publish them back to Visual Studio Team System. In this case, the new tasks you have just created will be acting as summary tasks in Office Project and do not need to be published to Visual Studio Team System. To ensure that the tasks you just created for your iterations do not get published, move to the Publish And Refresh column (the last in the task list) and change the value from Yes to No. Do this for each of the new tasks you created.

6. Link the Office Project tasks that you just created together by selecting the tasks that specify the iterations and then choose Edit | Link Tasks.

7. Assign scenarios to iterations by moving the tasks that represent the scenarios you imported from Visual Studio Team System as sub-tasks of the iteration task you want the scenario to be developed in. To do this, drag the task row for the scenario to a location under a task that specifies your iteration. On the Formatting toolbar, click the right green arrow to indent the scenario, which makes it a sub-task of the iteration. You must also select the appropriate iteration value from the drop-down Iteration Path list of each scenario. Continue this process until you have moved all of your scenarios under the iteration that they will be released in.

8. Next, select all of the tasks in Office Project, right-click the selected tasks, and on the shortcut menu, choose Task Information. On the Advanced tab, on the Task Type dropdown list, select Fixed Duration, and then click OK.

9. For each of the scenarios listed under each iteration, specify the duration equal to the duration of the iteration. For example, if your iteration length is 3 weeks, set the Duration field for each scenario to 3 w. You should be left with a project plan that looks similar to Figure 4-7.

   
   Figure 4-7: An initial release plan in Office Project

Setting the duration of all of the requirements to the length of the iteration might seem a bit strange at first; however, remember what we are trying to do with this level of iteration planning. We simply want to assign scenarios to be the focus of an iteration. You should not be worried about sequencing these scenarios within an iteration because rarely will developers work on one feature at a time during an iteration. Also remember that the duration of a task is much different than the effort required to complete the task; the tasks were changed to Fixed Duration in step 8 in the earlier procedure because you don’t want the duration to change if you make changes to Work and Assignment fields.

Ordering Scenarios

How you choose to sequence scenarios throughout your project will depend on many factors. One of the most important factors is determined by what the customer would like to see first because these scenarios will have most probably scored higher in requirement prioritization. Many organizations start with the highest priority requirements and work their way to the lowest priority requirement when performing scheduling. You should also take into consideration some of the technical details of each of the scenarios. For example, a scenario might have the highest priority but depend upon a number of other scenarios or quality of service requirements to be complete before it even makes sense to begin implementation. In this case, the dependent scenarios will need to be scheduled first. You should ensure that you understand the priority and the dependencies of your requirements to best develop your project plan.

Creating Work from Requirements

Now that you have provided an initial release schedule for your project, you should next derive work from your requirements. In this step, you will determine what the team must do to deliver the feature. Work might include detailing the requirements, performing further analysis, conducting design sessions, writing test cases for the requirement, developing code that implements the test cases, performing user acceptance testing, and so forth.

Your entire team should be involved in decomposing scenarios into tasks. You will first identify tasks that may not be associated with any specific requirement, such as setting up the development and build environments. From there, you will go through all documented requirements and attempt to come up with a list of actions that your team will need to take to implement that requirement. You should also provide an estimate for the amount of work it will take by a team member to complete each task.

It is important to try to maintain traceability between your requirements and all derived tasks. That is, all of the tasks that you create should have a link to the requirement that spawned them. The fastest way to spawn tasks from your requirements is through Visual Studio. Perform the following steps to create tasks that relate to a requirement:

1. In Team Explorer, launch the All Scenarios or All Quality of Service Requirements work item query.

2. Right-click a scenario or quality of service requirement work item from the work item Query Create Results window and choose Add Related Work Item | Task from the shortcut menu.

3. A new task work item will be created for you and given a default name that indicates that it is related to the requirement you originally selected. Notice that in the Links tab of the work item from the original risk are references providing traceability between the requirement and the task. Type the details of your task and save it as a new work item.

On many occasions, one task may be derived from many requirements. For example, you might have a task such as create user interface prototype, which would link to every scenario the prototype will demonstrate. To do this, you must add links from each of the tasks to the appropriate scenarios. To perform this task, follow these steps:

1. Create a new task work item from Team Explorer by right-clicking the Work Items folder under your Team Project and selecting Add Work Item | Task from the shortcut menu.

2. Enter the details for your task such as its title, related discipline, and the area to which it belongs to.

3. On the Links tab, click Add.

4. In the Add Link dialog box, specify Work Item as the link type, and then click the Browse button next to the Work item ID field. The Choose Related Work Item dialog box appears.

5. On the Saved query drop-down list, choose All Scenarios and then click Find to return the results of the query.

6. After the work items appear, click the scenario work item you want to associate your new task with and then click OK.

7. Add a comment to the linked work item if you want and then click OK.

8. Repeat steps 3 through 7 for all of the scenarios you want to associate with your task.

Of course, you can always add links to tasks from the scenario, and the method you choose will depend on whether it is easier to link tasks to scenarios or scenarios to tasks on your project. In either case, the results will be the same. In fact, you can also use Office Project or Office Excel to perform this type of linking. More on this topic will be covered in the next section.

Project Spikes

Sometimes it is very difficult to break a requirement down into the tasks required to develop it because of the uncertainty that may exist around the requirement itself or the approach on its implementation. For this reason you can schedule a spike, which is a specific fixed-duration task (usually 3 to 4 hours) with the sole intent of gaining further knowledge or understanding of a problem. For example, your project team may need to use a new technology that no one on the team has used before. Because of this, the team cannot provide a good breakdown of how to use the technology or provide an estimate for any work using the new technology. If this is the case, you can elect one or more people to spike on the technology to gain a better understanding of it so that you can make a more accurate estimate. In its simplest sense, a spike is used to reduce the amount of uncertainty of some aspect of your project. Because higher uncertainty typically drives a greater range of estimates, spiking activities will actually provide you with greater accuracy in your related estimates.

Refining the Project Plan

Now that you have decomposed your requirements into tasks, it’s time to add these new tasks to the plan you created when you constructed the initial release plan. In fact, you will use a very similar technique in adding tasks to your project plan as you did when you added requirements to iterations to create an initial release plan. You will add these new tasks to your release plan and make them sub-tasks of the requirements they relate to. If the tasks do not relate to requirements, such as creating a build environment or the construction of a testing lab, these tasks will be set up as sub-tasks of the Office Project tasks that represent iterations. To add tasks to your plan, perform the following steps:

1. Open the release plan you created earlier in this chapter.

2. Add the Remaining Work field to the release plan by right-clicking the column heading of the Duration field in your plan and selecting Insert Column from the shortcut menu. In the Field name list in the resulting dialog box, select the Remaining Work field and click OK.

3. Choose Team | Get Work Items, and then in the Get Work Items dialog box, on the Saved query drop-down list, select All Tasks. Click Find to return a list of task work items.

4. Select the tasks you want to add to your project plan. By default, all of the tasks will be selected indicating that they will be imported into your plan. Click OK to load the tasks into Office Project.

5. All the tasks will be added to bottom of the work area, and you must reorganize the tasks under the appropriate iteration or requirement summary tasks. Before you can do this, select all of the new tasks, right-click, and then select Task Information from the shortcut menu. On the Advanced tab, change the Task type to Fixed Duration.

6. To move the imported tasks to their appropriate location within the Office Project file, drag the individual tasks you just imported as sub-tasks to the iteration in which they will be performed. If you created the majority of these tasks as work items related to your project’s scenarios or quality of service requirements, the iteration path of these tasks will automatically be set to the iteration path of the source requirement.

7. If a task has a work item link to a single scenario or quality of service requirement, move the task directly under the scenario in the project plan and indent the task, making the scenario or quality of service requirement a summary task and the new task its child by clicking the green indent arrow on the Formatting toolbar.

8. After rearranging all the tasks, set the Duration field of each task to the duration of the iteration. The resulting plan should look similar to Figure 4-8.

   
   Figure 4-8: A project plan showing iterations, requirements, and tasks

9. The Remaining Work fields represent an estimate for the effort for each task. For each task you entered into the project plan, provide the work effort in the remaining field.

10. Using the Resource Name field, select the team member that has been modified to provide you a list of your team members.

11. When you have completed your plan, publish all of your changes to the Team Foundation Server by choosing Publish Changes from the Team menu in Office Project.

    Tip 

    Remember that you can also add new tasks directly into Office Project in virtually the same way you would with Office Excel. You can work with Office Project in an offline mode, publish and refresh work items, and edit areas and iterations all from the Team menu in Office Project.

Notice that the tasks were not sequenced in any further detail than simply being assigned to an iteration or a requirement. You may have also noticed that the duration of each task was set to the length of the iteration itself regardless of how much effort was assigned to the task. The reason for this is to maintain simplicity. In Office Project, the duration of a task does not need to be related to the effort required to complete the task. In addition, your team members will rarely work serially, choosing to perform work in parallel throughout an iteration. This behavior should be encouraged because it allows your team members to remain productive while you are still expecting to have completed work by the end of the iteration. If the iterations are small enough, the order in which work assigned to the iteration must proceed is quite apparent. Our project plan simply states that it must be done by the end of the iteration, saving us the work of going into greater detail by sequencing activity within an iteration. Of course, if the size of an iteration is long and the sequencing is critical, you can go further and specify this in the project plan as you would with any Office Project plan you may have created in the past.

Using Office Excel for Project Planning

As a project manager, your tool of choice might not be Office Project but Office Excel. Office Excel may not provide you with the ability to produce great looking Gantt charts, but it nonetheless provides some very powerful features. These features enable you to plan your project just as effectively as you might with Office Project while forcing you to maintain a simple approach to the planning exercise. Instead of working with task summary tasks and calendar durations, you will simply be left to work with column filtering and ordering features to organize work into iterations.

If you created a project workbook as described earlier in this chapter, you should be ready to start organizing work into iterations. As you did with Office Project, you should start with the All Scenarios tab (assuming that you created a workbook that linked to the All Scenarios work item query). Here, you will simply assign scenarios to iterations by using the drop-down list in the Iteration Path column for each scenario. When you have completed assignment of iterations, you can use the All Tasks tab to perform the same steps to assign task work items to their corresponding iterations. Unfortunately, there is no good way to see how tasks link to requirements from inside Office Excel, or in Office Project for that matter, unless you check for linked work items one work item at a time. If you add the Links & Attachments work item field to your list, you will see only the values Yes or No, which indicate only the existence of a link or an attachment for each work item. If you want to see what those links and attachments are, select the work item that has attachments or links and choose Tools | Links & Attachments in Office Excel.

Note 

Another limitation of using Office Excel and Office Project to enter work items is the inability to add associated work items as you can in Team Explorer.