Agile planning tools in Visual Studio team System 2010

This article is based on a pre-release version of Visual Studio team System (VSTS) 2010. All information is subject to change.

This article describes the following:

Product and Iteration Planning

Product Backlog Workbook

Capacity Planning and reporting

Iteration Backlog Workbook

This article uses the following techniques:

VSTS 2010, VSTS Process for Agile Software Development 1.0

Are there any semantic contradictions in the agile program? I hope you don't think so, but at a recent ad hoc Group meeting in Los Angeles, one of the participants pointed out that the organization had shifted from agile development to a more formal approach. After further questioning, she admitted that her team could no longer follow the verbal requirements of her manager to fix the code and immediately deploy the repair results to production. Now she has to use a formal procedure. For her, that means giving up agile development.

In fact, her understanding of agile development is not accurate, but I am very happy that her organization can develop formal change processes. Agile does not mean to blindly speed up or to choose agile for speed reasons. Instead, it is a standard planning method and incorporates empirical data.

Visual Studio Team System (VSTS) 2010 introduces new features and features to help Agile teams plan. In this article, I'll introduce you to some new product backlog workbooks, iteration backlog workbooks, and a new set of reports that can help agile teams plan and manage versions and iterations.

Long-term planning

People are always worried that there is no precise long-term planning, which has become the main obstacle to the promotion of agile methods. In the 2008 Agile Development Survey, the lack of prior planning was the most concerned issue for respondents in adopting agile methodologies. I suspect that for many people, the lack of precise long-term planning is tantamount to a lack of collaborative planning. Agile teams Select multiple levels of planning and make periodic corrections during the waterfall planning process, which is certainly the case.

In the uncertainty cone of software evaluation, Steve McConnell that premature evaluation in a project may result in inaccurate results, with a high margin error of up to 400%: "In the early stages of the project, details of the nature of the software, specific requirements, details of the solution, project planning, Personnel composition and other project variables are uncertain. The variability of these factors can lead to the variability of project evaluation. ”

Of course, this does not mean that the manager's management strategy is "we do not know when the project will be completed, and do not know what it would be like." It's actually a way to explain how the team plans the version and the scope of the work done in each release is variable.

Figure 1 Product and Iteration Backlog