Estimating Work and Scheduling with Visual Studio Team System


To this point we’ve talked about how to create an iteration plan by scheduling scenarios into iterations, splitting the stories into tasks, and then finally estimating the tasks. What happens if you don’t have enough time in your iteration to perform these tasks? In fact, there is a big difference between estimating and scheduling. Up to this point we have assumed that since we assigned a scenario to an iteration, all of the tasks that derive from the scenario should get done in that same iteration; however, what if there just isn’t enough time? And even more importantly, how much time do you really have to spend working on tasks in an iteration anyway?

Let’s start to answer this question by looking at how we work. As asked in Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Prentice Hall, 2003), during an 8-hour day, is an average person able to complete 8 hours worth of work? Probably not. You should try to take into account team meetings, washroom breaks, e-mail, instant messaging conversations, and hallway conversations, and you are more realistically looking at about 5.5 hours. You should also take into account issues such as vacation, sick time, education and training time, and time for other activities. Therefore, you should likely assume that each team member can productively work 42 to 43 weeks per year and 5.5 hours per day.

Now, assuming this, let’s get back to our iteration plan. Let’s assume that an iteration is two weeks long. We will need time at the end of the iteration to get our release ready and deploy it to test servers; let’s just assume that will take 4 hours. We will need time at the beginning of the iteration to review the iteration plan, our estimates, issues, schedules and so forth. As iterations continue, we will need to allocate time to bug fixing and stabilization. Let’s add these up to see what we are left with in Table 4-2.

Table 4-2: Resulting Work Allocation
Open table as spreadsheet

Activity

Required Time

Iteration planning

.5 days per iteration

Bug fixing

1–3 days per iteration

Stabilization of build

1 day per iteration

Packaging and deploying to test servers

.5 days per iteration

Total

3–6 days per iteration

If an iteration takes 10 days (two weeks), and we are using 3 to 6 days per iteration to work on tasks not related to writing code or testing, that leaves us only about 4 to 7 days to actually write code. If we then take our previous assumption, that the average developer is productive only 5.5 hours per day, we are left with 22 to 38.5 hours of productive work in a two-week period.

When team members provide you with estimates, they are likely not taking into account all of the other factors we just discussed. When asked how long a task will take, the estimate is likely given as if the team member were working on the task uninterrupted, something Cohn refers to as perfect days. From these estimates, we can now start assigning tasks to iterations; however, armed with the knowledge that our two-week iteration has only 22 to 38.5 hours of time, we can make a better decision on just how much work to assign to the iteration while ensuring that total work does not exceed 38.5 hours per team member per iteration.

Checking Estimates and Schedules by Using Pivot Tables

Unfortunately, Visual Studio Team System doesn’t provide any extra tools to take all these considerations into account when planning iterations. Perhaps the best tool you can use to ensure that you are not over-scheduling work for your team members is an Office Excel pivot table. Earlier in this chapter, you learned how to construct a pivot table from the All Work Item list in Office Excel. Perform the following steps to create a similar pivot table that will help you understand estimated work per iteration for each of your team members:

  1. Open the project workbook you created earlier in this chapter and find the All Work Items list.

  2. Ensure that the list displays all of the required columns and the Remaining Work field. To do this, click anywhere in the list and select Team | Choose Columns. In the Choose Columns dialog box, click Add Required to add all required fields. From the Available columns list, select the Remaining Work column, click > to move the column to the Selected columns list, and then click OK to continue.

  3. Click anywhere in the list and select PivotTable And PivotChart Report from the Data menu in Office Excel to display the PivotTable And PivotChart Wizard.

  4. Accept the default settings in step one of the wizard, using an Office Excel list or database as the source of the pivot and a PivotTable as the target. Click Next to proceed to the next step in the wizard.

  5. Accept the default range selection provided to you by the wizard. Here the wizard has selected the All Work Items list as its source. Click Next.

  6. Accept the default selection of a creation of a new worksheet for the PivotTable report and click Finish.

  7. Drag Iteration Path, Assigned To, Work Item Type, and Title fields to the Drop Row Fields Here area of the pivot table. Ensure that you drag the fields onto the Row Area in the same row order as they are specified in this step.

  8. Drag the Remaining Work field to the Data area of the pivot table. By default, the formula that will be used to summarize the Remaining Work data on each of the pivots will be the Count function. To change the function to Sum, right-click the Count Of Remaining Work cell and select Field Settings from the shortcut menu to display the PivotTable Field settings dialog box. Select Sum from the Summarized by list and click OK. The value of the Remaining Work field will now be added together for each dimension of your pivot table, as you can see in Figure 4-9.

    image from book
    Figure 4-9: Pivot table for viewing workload by team member for each iteration

    Tip 

    If you are using the MSF for CMMI Process Improvement, you should use the Estimate field instead of the Remaining work field.

The pivot table you just created is read only, meaning that you can’t make any direct changes to the values that are displayed within it. As you make changes to task assignments and iteration categorization in other parts of the project workbook, you should regularly publish any changes back to Visual Studio Team System, refresh the All Work Items list, and refresh the pivot table you just created by right-clicking anywhere on the surface of the pivot table and selecting Refresh from the shortcut menu. The pivot table will give you a handy representation of the workload as you progress throughout the planning cycles.

image from book
More Elaborate Estimating

If there is any aspect of software development that could be considered an art form, it is the estimating process. Very rarely are teams happy with their estimating techniques because most organizations underestimate rather than overestimate work. On the other hand, just as air expands to fill its container, so does work and estimation. That is probably one of the main reasons why overestimating isn’t very common. This book is not going to detail the finer arts of estimation because entire books have been dedicated to the subject. If you are interested in fine-tuning your team’s estimating abilities, you should read Agile Estimating and Planning by Mike Cohn (Prentice Hall PTR, 2006) and Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Both of these books provide an enormous amount of insight into estimating providing you with a great opportunity to learn about how to improve your approach to this topic.

image from book




Managing Projects with Microsoft Visual Studio 2005 Team System
Managing Projects with Microsoft Visual Studio 2005 Team System
ISBN: 735622167
EAN: N/A
Year: 2007
Pages: 93

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net