Chapter 11
Agile Planning and Tracking
What's In This Chapter?
- Defining and managing your product backlog
- Planning an iteration while balancing resource capacity
- Tracking your work using task boards
- Understanding options for customizing the agile planning and tracking tools
The Agile Manifesto defines several guiding principles that have implications on the ways in which teams manage projects. Instead of attempting to define an entire project schedule up front, as with a waterfall methodology, an agile team allows the plan to evolve over time. Work is broken down into multiple successive iterations, each of which might last between one and four weeks.
Teams practicing an agile development methodology tend to embark upon a journey of mutual discovery with their customers to determine new work dynamically, based on changing business priorities or on feedback from work done in previous iterations. The customer, or at least a proxy for the customer, is considered a virtual member of the team and participates in defining and prioritizing (and often re-prioritizing) work over time.
The pursuit to embrace agile development, with dynamic schedules and evolving requirements, has meant that many of the tools and techniques used for traditional project management are no longer sufficient. Agile practitioners have needed to look for different ways of capturing work, balancing resource capacity, tracking status, and so on.
Scrum, which is by far the most popular agile development methodology in use today, defines such tools, terminology, and methodology. Future work is captured and prioritized on a product backlog, which can then be committed into specific iterations, called sprints. Each sprint has its own sprint backlog in which work is further decomposed into smaller units of work. This work is tracked to completion on a task board, which usually takes the form of sticky notes on a whiteboard.
Team Foundation Server 2012 has embraced these concepts by providing a set of web-based tooling for managing your product backlog, decomposing your work into iterations, and tracking your work using a digital task board. Anyone familiar with or practicing Scrum should feel immediately at home with this set of tooling, although it cannot be understated that this same set of tooling can be adopted by any team who wants to use it, even if they aren't practicing Scrum per-se. One of the design principles of Team Foundation Server has always been that teams can use any process they want to, and Team Foundation Server provides the right level of flexibility and customization to support such a process.
In this chapter you find out about the new web-based tooling available within Team Foundation Server 2012 to support agile project management and tracking. This book is not a true primer on how to run a project using a Scrum (or any other) development methodology, but there are several great books to choose from which cover this topic.
Defining a Team
Team Foundation Server 2012 has introduced the notion of a team, which you can use to organize people who are working together. This should not be confused with the concept of a team project within Team Foundation Server, which is a large container of work, consisting of source control and work items that all share a common process template. A team project can contain multiple teams, and each team can have its own product backlog, iterations, and task board. A single person might also participate in more than one team. For instance, a graphic designer might be a shared resource responsible for contributing artwork to different teams.
To create a team, follow these steps:
If you just created a brand-new team then your home page won't yet look as rich as the one shown in Figure 11.5. The top half of this view shows information relevant to your current iteration. The status bar on the left shows the amount of work remaining as compared with the capacity of your team (in this example, there are 39 hours of work remaining and the team has a total capacity of achieving 42 hours of work). The burndown graph is a trend that shows how remaining work has decreased (or increased) over time during your current iteration. You learn more about iteration capacity and burndowns later in this chapter.
The bottom half of this view shows any Team Favorites you have configured. These can represent queries—such as open bugs, or in-progress tasks. They can also display graphs of recent builds, or even recent changesets that have been checked into a particular branch. To add Team Favorites to this view, you should first open a relevant query, branch, or build within Team Web Access. You can then click the small dropdown arrow located to the left of the object and select Add to Team Favorites, as shown in Figure 11.6. This adds a new tile to your team's home page, which can make it easy for the entire team to see the metrics you believe are most important to track.
Next, you see how to define and manage your team's product backlog.
Maintaining Product Backlogs
A product backlog is essentially just a list of work that your team has identified but hasn't yet scheduled for implementation. The product backlog is a useful tool for collaborating with customers or other project stakeholders. As new work is requested by your stakeholders, you can track it in a central location on the product backlog. You can also estimate and prioritize this work can, usually with input from your customer or stakeholders, to help determine which items are most important to deliver first.
From your team's home page, click View Backlog to display your product backlog, such as the one shown in Figure 11.7. The “quick add” panel at the top of this page enables you to quickly enter new work as it is identified. You can select the type of work to add (such as Product Backlog Item or Bug), provide a title, and press Enter (or click Add) to quickly add this work to your backlog. When you do this, you automatically create a new work item within Team Foundation Server.
If you highlight a row within your backlog, any new work you add from the “quick add” panel is inserted above this highlighted row. The exception to this rule is if you have highlighted the last row in your backlog; new work is added at the end of your backlog.
You can easily reprioritize work by simply dragging and dropping it on the backlog. Changes you make here are saved to Team Foundation Server in the background. You can also double-click an item in this view to open the work item editor to provide additional detail or make changes.
Teams practicing Scrum will be familiar with a concept known as velocity. Velocity is a metric used to calculate the amount of work that a team is able to deliver for a given iteration. It is usually measured in story points on Scrum teams. Other teams may prefer to do their estimations in hours, or days, or ideal days, and so on. Regardless of the estimation technique used by your team, you can use the product backlog view to get a sense for when you will be able to deliver items on your backlog. The only requirement is that you should be consistent with your estimation techniques. For example, when some people on the team are estimating in days and other people are estimating in story points, it's difficult to create consistent plans.
Toggle forecast lines on or off by clicking on the “on/off” link in the upper-right of this page labeled “forecast.” Forecast lines display, as shown in Figure 11.7, to indicate when work is estimated to be delivered based on your current team's velocity. This approach requires that you have estimated your backlog items by providing a value for effort. Do this by double-clicking each item in your backlog to provide this additional level of detail.
The Forecasting Based on Velocity Of textbox enables you to experiment with different values to see the effect that given values for velocity might have on delivering work. For example, you might be able to ask for additional funding from your customer to hire new team members and speed up the rate at which items are delivered. Or you might know that there are several upcoming holidays that will affect your team's ability to deliver. You can also click the velocity graph in the upper-right corner of this screen to see your historical velocity for the preceding (and current) iterations.
The forecast lines are purely estimates. In order to actually schedule work for a given iteration, you can drag and drop it onto either the current or future iterations listed on the left-hand side of this view. When you drag and drop work onto an iteration the value in the Iteration Path column is updated to reflect the assigned iteration, and the Iteration field is updated within the work item in Team Foundation Server.
Planning Iterations
After you have identified the work that you want to deliver for a given iteration, you can click an iteration from the list on the left-hand side of the product backlog view to open the iteration planning view shown in Figure 11.8. This figure shows an iteration that is mid-sprint, meaning that the team has already completed some work and is preparing to finish this iteration.
When you first add items to an iteration (such as a product backlog item, or a bug) you are only declaring your intention to deliver this functionality. The next phase of planning this work is to actually break it down into the individual tasks that people on your team need to complete in order to perform the work. Click the plus (+) sign next to an item in your iteration contents to display the dialog shown in Figure 11.9, which enables you to add a new task work item as a child to the parent you clicked on.
You should provide a title for this task and, if possible, an estimate for the amount of remaining work. By default, remaining work is assumed to be provided in hours, but you can also customize this (see “Customization Options”). You can assign this to a team member who will complete this work, but you are not required to do so. Save this work item and proceed to break down the rest of your work into child tasks. If you haven't already done so, set the state of parent work items to Committed as each item is broken down.
As you begin to create tasks with values for remaining work, you will notice that the capacity graphs on the right-hand side of this screen begin to render. These graphs are broken into three areas:
- Work—shows the total amount of work remaining for this iteration, calculated as the sum of the remaining work across all task work items.
- Work By:Activity— enables you to categorize the amount of remaining work into categories. When creating tasks, you can use the activity field to categorize tasks, such as Documentation, or Design, and so on. If you don't provide a value for activity, work simply shows up as Unassigned.
- Work By:Assigned To—shows the amount of remaining work that is assigned to each person on your team.
Click the Capacity tab to assign the capacity for each of the members of your team as shown in Figure 11.10. The Capacity Per Day column enables you to specify the average number of hours per day that a given resource is working on tasks. The Activity column enables you to specify the discipline of a team member, which is necessary if you want to view capacity by activity type. Finally, you can use Days Off to define days that a team member is sick or on holiday, and you can use Team Days Off to define days that the whole team will be unavailable, such as during a holiday or company retreat.
The values you enter for this table are specific to this team and this iteration. So a shared resource who works on multiple teams might have different values for Capacity Per Day or Days Off depending on the team. Also, a resource who works five hours per day on one iteration might only work two hours per day during a subsequent iteration.
After you assign capacity values for your team, the capacity indicators on the right change to either green, if a resource is at or under capacity, or red, if there is too much work given the planned capacity. The iteration plan is designed to be viewed on a regular basis so that you can make adjustments to the plan as needed. For example, if a team member is sick, you might need to reschedule work that was originally planned for this iteration. You can drag and drop parent items from this list onto other iterations on the left-hand side of the page.
Tracking Work
When you are satisfied with the iteration plan, it's time to start writing code, authoring documentation, designing user interfaces, and doing all the other work that's required to develop great software. During the course of this activity, it can be helpful to have a single location to easily determine the status of the work that everybody is doing.
Scrum teams typically use a task board for this purpose. In its simplest form, a task board takes the form of a whiteboard with sticky notes on it that you move from the left side of the board (work that is not yet started) to the middle (work that is in progress) to the right (completed work). This technique works very well for teams that are co-located, especially if they share a team room, because anybody can quickly look up at the white board to determine the state of the team's work. Of course, this approach has its challenges for teams who work in different locations or have individual offices.
Team Foundation Server 2012 provides a digital task board that overcomes the limitations imposed by traditional physical task boards. Click Board at the top of Team Web Access to access the task board shown in Figure 11.11.
Each row on this task board represents a parent backlog item from your current iteration. The tiles on this task board represent the individual child tasks that you created. Each task begins in the To Do column. When a team member is ready to begin a task, he can drag and drop it onto the In Progress column. As he makes progress against a given task, he can click the number on the task to update the remaining work. Or if he has finished as task, he drags it into the Done column to automatically set the amount of remaining work to 0. Clicking the name of the team member for a given task opens a dropdown menu that enables you to quickly reassign work.
Double-click a task to open it in a full editor, such as the one in Figure 11.9. This is often helpful if you realize that a task is going to take more time than originally estimated, and you need to increase the amount of remaining work.
The entire interface is touch-friendly. If you have a touch screen monitor, such as in a shared team room, you can configure it to display your task board and make it easy for team members to update the status of their work whenever they walk by it. And because everything is stored in Team Foundation Server, remote workers can access the same view in any modern web browser to see what their colleagues are working on and provide their own statuses.
If you find yourself constrained for space in this view, you can collapse finished backlog items by clicking the arrow to the left of the parent work item title. You can also use your browser's zoom functionality (usually Ctrl + - and Ctrl + +) to fit more work on a single screen.
You can generate a personalized view of this screen by clicking the Person: All link and selecting the name of any team member. This highlights the work that is assigned to that team member, making it easier to differentiate from the rest of the team's work.
You can also click the Team Members tab to display a view in which tasks are organized by the team member they are assigned to, instead of by their parent work item. This is a helpful view for team meetings, where team members might be expected to tell their peers what they worked on yesterday and what they are planning on working on today. This view is also helpful for seeing whether there are any team members with too much work remaining, and whether other team members might have capacity for picking up some of that work.
As work is finished, the team can transition parent backlog items to a state of Done. Open a parent backlog item by clicking the title of the item on the left-hand side of the screen. This state transition is not done automatically when all of the tasks are finished because there may be additional checkpoints or quality gates in place before work is considered to be truly finished. For example, you might want to request feedback from your project's stakeholders to ensure that everybody is satisfied with the work as it has been implemented.
The burndown graph in the upper-right corner of this screen displays a trend of the remaining work over time for your iteration. This graph is updated in real time as your team completes work (or identifies new work) during the course of an iteration. You can display the burndown graph in full screen by clicking it, as shown in Figure 11.12.
Customization Options
As mentioned previously, the examples in this chapter follow the default experience you get by using the Visual Studio Scrum 2.0 process template for a team project. If you are practicing Scrum today, then you are likely already familiar with the types of tools available in this chapter. But even if you aren't practicing Scrum or using the Scrum process template, you can still benefit from these tools.
Depending on the process template you choose, the default terminology and views might vary. For example, a team using the MSF for CMMI process template tracks Requirements instead of Product Backlog Items as the parent work item type to be planned. An MSF for CMMI task board contains four columns (Proposed, Active, Resolved, and Closed) instead of the three shown earlier for a Scrum project (To Do, In Progress, and Done).
If you are using a team project that was created using one of the process templates provided by Microsoft with Team Foundation Server 2012 (Scrum 2.0, MSF for Agile 6.0, or MSF for CMMI Process Improvement 6.0) then this tooling is preconfigured automatically to work with your team projects. If you are upgrading an existing team project from an earlier release of Team Foundation Server then you need to perform some additional steps in order to begin using the agile planning and tracking tools mentioned in this chapter. These steps are outlined at http://aka.ms/TeamProjectUpgrade.
There are also several ways you can customize these tools to change their appearance and behavior. For example:
- Add or remove fields from the “quick add” pane in the product backlog view. For example, in addition to setting a title, you might also want to specify an effort estimate with each new item.
- Add or remove columns from the backlog and iteration views.
- Change the list of activities that task work items and team members can be assigned to.
- Change the working days to be used when calculating capacity and rendering the burndown graph. By default, Saturday and Sunday are considered nonworking days, but you can modify the days.
- Configure the types of work items to be used as parents and children throughout the tooling.
All of these customizations and more can be configured by following the steps outlined in the documentation at http://aka.ms/CustomizingProcess.
Summary
In this chapter, you discovered the new tools available with Team Foundation Server 2012 for planning and tracking work in an agile manner. You found out how to use the product backlog view for defining and managing items that your team may schedule and implement in the future. You then saw how to break down work for an iteration into tasks and examined the remaining work for these tasks against the capacity of your team.
Finally, you learned about using the task board to track work during the course of an iteration so that everybody on the team can easily understand what their colleagues are working on and how much work is left to deliver in an iteration.
In Chapter 12 you find out how you can use the rich sets of reports and SharePoint dashboards to provide even more information that can be used to better manage your software development projects.