In this exercise, you will learn how to use Team Foundation Server to manage your product backlog, create work items, break work items into tasks, and assign tasks to team members. The new backlog features enable you to easily do all of this work while keeping an eye on team capacity.
- Log in as Julia. All user passwords are P2ssw0rd.
Launch Internet Explorer from the taskbar and select the TFS Web Access button from the favorites bar at the top.
Figure 1
Launching the team web access site
There is also a
Web Access link in the Team Explorer window within Visual Studio.
The Home view for the Fabrikam Fiber Web team provides a high-level overview of the current iteration (Sprint 3) including team workload versus capacity, burndown of tasks over time, and Team Favorites, which can include a configurable assortment of work item queries, build definitions, and version control path. In addition, there are links to quickly create new work items and bugs, load the backlog, task board, initiate requests for feedback, and so on.
Figure 2
Fabrikam Fiber Web team Home view
Team Favorites can be added or removed from within the team web access portal. For example, navigate to the Build tab to assign build definitions as a team favorite. In addition, team favorite work item queries can be modified from within Visual Studio.
As you can see under the Members section, there are several members listed in this team. Teams are a new concept introduced in Team Foundation Server 11 to make it easier to manage, assign, and track work. This team is responsible for handling all of the engineering work associated with Fabrikam Fiber’s web presence.
Select the team drop-down box in the top-right corner of the portal and note that there is one project and one team listed. Press the Escape key to keep the current team selected.
Each team can have different Team Favorites listed, different work capacity, and even different work items. The determining factor on where a work item will show up is governed by the Area field.
Navigate to the backlog by selecting the View backlog link under the Activities section.
Figure 4
Navigating to the backlog
The product backlog contains work items that have not been assigned and committed to an iteration. These product backlog items represent user stories that will eventually be broken down into smaller tasks for the team to take on.
Figure 5
Product backlog view
The Current iteration shown in the tree on the left side of this screen is Sprint 3. Team Foundation Server uses the current date and time to determine the current iteration. The virtual machine you are using has been hard-coded to use a date of February 15, 2012 for purposes of this lab. This date is set each time you boot up this virtual machine.
If your virtual machine has been running for a while, it may no longer be set to February 15, 2012. If so, you should manually set the date on your virtual machine to 8:00 a.m. on February 15, 2012. However, if you have modified work items or source control in Team Foundation Server prior to starting this hands-on-lab, it is recommended that you restore this virtual machine to its original state prior to completing this lab.
Imagine that the VP of Fabrikam Fiber has requested that a new user story be implemented for the customer-facing service portal. This new user story will enable customers to see weather-related service outages. In the Contents section for the Product Backlog, select the last row and then create a new Product Backlog Item with the title “Customer should see weather-related outages on portal.”
Figure 6
Adding a new user story to the product backlog
New work items are generally inserted above the selected location. The exception is that if you select the last work item, the insertion will be after the selected location.
Select the Add button to add the new user story to the backlog.
Figure 7
Adding a new user story to the product backlog
Work items on the product backlog are ordered based on priority, with high priority items at the top. Our new work item has a high priority, so move it to the top of the list by dragging and dropping it into place.
Figure 8
Increasing the priority of the new user story
Let’s edit the new user story to assign it to the appropriate product owner and record an initial estimate of expected effort. Double-click on the new user story.
Figure 9
Editing the new user story
Assign the new item to Brian Keller (the product owner for the Fabrikam Fiber Web Team), set the state to Approved, set an initial effort of ‘8’, and then select the Save and Close button.
Figure 10
Assigning the new user story and estimating effort
Each team may choose to define the
Effort value as they see fit, using a unit of story points, hours, days, or number of sodas required. The point here is that this measure is a relative value with respect to other work items. Work will be broken down into hours later.
A popular planning approach that helps to eliminate groupthink and considers input from all team members is known as planning poker. You can read more about it at
https://en.wikipedia.org/wiki/Planning_poker.
Assign the new user story to the current iteration, Sprint 3, by dragging and dropping it as shown below.
Figure 11
Assigning the new user story to the current iteration
If you are a Scrum purist, you are probably cringing at the fact that we just added new work to a mid-flight iteration. While this is something you might never do in the real world, this is a shortcut taken for purposes of this lab in order to simplify the workflow and still show you all of the aspects of the new project management interface. Well, that, and the VP told you to.
Look at the Iteration Path for the new user story to make sure that it is assigned to Sprint 3 as expected. This user story will remain on the product backlog until the team commits to taking it on.
Figure 12
Assigning the new user story to the current iteration
The product backlog view also provides a velocity chart that shows the amount of work that the team has undertaken in each sprint, with the current sprint breaking that down further to differentiate between work in progress and work completed. Click on the mini chart in the upper-right corner to load the larger view.
Figure 13
Location of velocity chart
During Sprint 1, the team completed 35 story points worth of effort. Sprint 2 was slightly more productive with 42 story points completed. The current iteration represented by Sprint 3 shows that we have completed 18 story points so far, with 23 remaining. Remember that these story points are a relative measure of effort that was agreed upon by the team.
Figure 14
Velocity chart showing progress towards completing user stories
- Press the Escape key to close the velocity chart.
The Product Backlog also includes a simple forecasting tool that you can turn on to get a rough idea of what can be accomplished in future iterations. Select the forecast link to turn it on.
Figure 15
Toggling the forecast tool to “on”
Note that the forecasting is currently being calculated with a velocity of 10, meaning that each future iteration will take on about 10 story points worth of effort. As you can see, Sprint 4 is actually forecast to include 11 story points. Backlog items that do not have Effort assigned are assumed to be 0, so it is recommended that this value is set before using the forecast tool.
Figure 16
Result of forecasting with a velocity of 10
The user story that we just added and assigned to Sprint 3 is the top backlog item listed, and it is NOT part of Sprint 4 even though it may initially look like that. Sprint 4 has a line under it and includes rows two and three.
As we saw from the velocity chart, that may not be aggressive enough for this all-star team, so click on the “10” value to change it to 35 and then press Enter.
Figure 17
Changing the forecasting velocity value
Now that we have the forecasting velocity set to a more realistic value, we can get an idea what the team can accomplish over the remaining iterations.
Figure 18
Changing the forecasting velocity value
The product backlog view also groups the past, current, and future iterations by their assigned dates. Select the Sprint 3 link so that we can break down work and assign it to the appropriate team members.
Figure 19
Navigating to the current backlog
In the backlog for Sprint 3, collapse the two user stories that have a state of ‘Done’ by clicking on the small triangles just to the left of the associated Titles.
Figure 20
Collapsing completed user stories
Before we break down the new user story, let’s take a quick tour of this iteration backlog view. To start with, it shows all user stories and associated tasks that are assigned to the selected iteration, regardless of state.
Figure 21
Current iteration backlog view
At a glance, you can see that the current iteration runs from February 6 to 17, with three work days remaining. Just to the right of the current iteration date range, there is a small graph showing the burn down of the remaining work.
Figure 22
Burn down graph
Click on the burn down graph to view it. The graph shows remaining work over the course of the sprint. The actual trend line makes it look like the team may not be able to finish the assigned work in time, but keep in mind that we still expect some work to be completed before the end of the current day (none has been recorded so far).
Figure 23
Enlarged burn down graph
- Press the Escape key to close the burn down graph.
Locate the overall Work bar that shows how close to capacity we are for the current iteration based on the total of the Remaining Work for the tasks in this iteration based on the total capacity for the team. It looks like we are okay now, but we still haven’t broken the new user story into tasks for the team yet.
Figure 24
Overall remaining work with respect to team capacity
Select the Capacity tab to look at the team capacity details.
Figure 25
Location of Capacity link
The capacity view allows us to specify the number of hours per day that each team member will be working on this project, as well as days off per team member, and overall team days off. These capacity settings apply to the current iteration. You can optionally use the activity column to describe the disciplines that each team member specializes in. When tasks are broken down by activity as well, it can provide you with another view across your team’s capacity to determine if, for example, you have enough people working on documentation to meet the demands for this iteration. For now, leave the capacity settings unmodified.
Figure 26
Team capacity settings
Return to the Contents view of the current product backlog.
Figure 27
Location of Contents tab
Imagine that we are meeting as a team to commit to the new user story and break it up into tasks. Double-click on the new work item and change the State from Approved to Committed, and select the Save and Close button. Once the team commits to the work, it will disappear from the product backlog.
Figure 28
Committing to the new user story
Select the button with the ‘+’ symbol in it to the left of the user story to add a new task. This will become a child task of the user story and will be used to help describe the implementation details required to complete this user story.
Figure 29
Location of the button used to create new tasks
For the new task, enter “Consume OData feed for weather alerts” for the Title, assign it to Cameron Skinner, and set the Remaining Work to 5 hours. Select the Save and Close button.
Figure 30
Creating a new task
- Select the button with the ‘+’ symbol in it to the left of the user story to add another new task.
For the new task, enter “Create UI for alerts” for the Title, assign it to Annie Herriman, and set the Remaining Work to 3 hours. Select the Save and Close button.
Figure 31
Creating a new task
Note that the new tasks were added as children of the user story and that some of the work effort bar graphs have now turned red, indicating that we have too much work assigned to the team based on capacity. Cameron is especially overworked as indicated by his individual capacity graph.
Figure 32
Product backlog for current iteration is now over capacity
It looks like the last user story in this sprint is a sizable one, and it hasn’t been started yet, so this could be a good candidate to reschedule for a future iteration so that the team can get back on track given their additional workload. Drag and drop the last user story, titled “Technician can edit customer contact details on Windows Phone,” onto the Sprint 4 iteration on the left-hand side of the window.
Figure 33
Using drag and drop to re-assign work to different iterations
Take another look at the overall Work bar once again to make sure it is now green. This means that we are well within the current team capacity. Just don’t tell the VP, or he might find another high-priority request for us to work on!
Figure 34
Remaining work for current iteration is within capacity