This blog provides a walkthrough of using the provided workbooks for iterative projects in the TFS 2010 MSF Agile 5.0 process template. First, let’s take a look at the Team Explorer “plug-in” in the Visual Studio 2010 IDE:
Next, we’ll go to the SharePoint project portal to show how Team Explorer echoes its structure. We first right-click the Team Project title node as follows:
This will take us to the SharePoint project portal as shown below. Note how Team Explorer simply mirrors this structure, with the ability to create new folders, upload documents, or copy/paste existing documents or folders.
Let’s now go back to Team Explorer, where we will select the Product Planning workbook (which is the Product Backlog for this Team Project):
After double-clicking the Product Planning workbook, we now see the Product Backlog worksheet as seen below. This is where you would perform bulk entry of work items for the entire project. This workbook is best used for Stack Rank exercises, setting Area Paths, and entering Story Points for balancing workload at the project level.
If you want to change the query, you can select the Configure dropdown and choose the List item as follows:
After selecting List, you will see a dialog that allows you to select the query you would like. The default product backlog is a flat query, so I would suggest you replace this with a hierarchical query.
Now we will select the Iterations worksheet, as seen below, where we can enter the start and end dates for each defined iteration. Based on the Story Points entered in the Product Backlog worksheet, you will see this workload in the Velocity graph. At the beginning of your project you will see what is planned, and as user stories are completed in individual iterations, you will see the hours delivered increase as well as color coding in the graph. Note also the Team Size field that specifies the rough amount of work that can be delivered within a given iteration.
Next, we will go the Interruptions worksheet, which will effectively block out dates that can’t be worked during the project duration.
Let’s now go back to Team Explorer, where we will select the Iteration Backlog for the first iteration. We will have an iteration backlog for each iteration. TFS seeds each Team Project with three iterations, but you can just copy and paste the iteration folders and modify to point the appropriate query under Team Queries. You will have to also perform a copy/paste operation under Team Queries and modify the query for each iteration. Generally, the idea is to perform the copy/paste/ modify operation of an iteration under Team Queries, and then perform a copy/paste/modify operation for an iteration under the Shared Documents folder.
After double-clicking, we will see the Iteration Backlog workbook as seen below. In this workbook, you will manage your entire iteration from worksheets in terms of scheduling tasks into a particular iteration, setting dates of the iteration for the burndown chart in the Burndown worksheet, interruptions for team members (personal or Holiday), and capacity planning for team members (which is a HUGE improvement over 2008, second only to hierarchical work items).
As with the Product Backlog, you can change the underlying query by selecting the Configure dropdown as seen below.
When you select List from the dropdown, you will see a dialog that allows you to select a different underlying query, as seen below.
When we select the Settings worksheet, we can enter the dates for the iteration, and the worksheet will calculate the number of days, as seen below.
Next, we can select the Interruptions worksheet, where we can enter dates for planned interruptions, and Holidays during this particular iteration. These dates are used to subtract hours from individual capacity in the Capacity worksheet.
Next, we have the all important Capacity worksheet. Next to the Burndown worksheet, this will be the second most used worksheet during any particular iteration. Notice here that I have scheduled Tasks in the Iteration Backlog which are reflected here, and you will also see the hours specified for vacation in the Interruptions worksheet have been factored in (i.e., I have 15 days available to work instead of the total 19 days of this iteration). Also, the Hours/Day field is used to specify the “ideal” hours any given team member is available to work (in my experience, 6 hours are typical, so developers have to be mindful when they make estimates that these are real estimates that don’t include water cooler chatter, bathroom breaks, or chatting with a significant other).
The green area in the Individual Capacity graph is the total amount of time a team member is available to work. The blue portion shows work actually scheduled in the iteration. The idea is to only schedule as much work as a team member is able to work. If a team member gets behind, which will be reflected in this graph from the Over field based on daily entry of time (which I will discuss shortly), then work can be rebalanced in this worksheet. As well, at any time you can go back to the Interruptions worksheet to add more time for any team member, and then can come back to the Capacity worksheet to rebalance.
As to time entry for team member tasks, this is something I’m pretty hard core on pressing home with customers. Quite simply, without daily time entry, burndown charts and reports are meaningless. In the Task work item, you will see the all important fields below:
Basically, when team members are sitting down doing estimates as a team (which I recommend), the team member will make an initial estimate. When the team member begins working on a particular task, each day they are working on that task, they will enter the hours remaining to complete the task, as well as the number of hours that were completed on that day. The original estimate should never be changed as it is used by TFS to calculate unplanned work. If the Remaining field goes up on a given day rather than down, then as I discussed above, this will be reflected in the Individual Capacity worksheet of the Iteration Backlog.
Our final worksheet is the Burndown, which is the definitive view on project progress. This will be used on a daily basis by the team lead to track project progress within an iteration. I won’t discuss in detail here, as there are many great places to learn how to properly interpret a Burndown chart. I may add some thoughts on this later, however.
That’s all for now. I will update this over the next couple of weeks to add more detail.