We've also added some new sample code for working with the version control APIs:

• Adding Items to the Version-Control Repository

• Editing Items

• Creating Branches

• Deleting Folders

The next thing on our backlog for the Team Foundation SDK is subscribing to events.

• Importance of the task
• Impact that help content will likely have on successfully completing the task

We gave the importance criteria a weight of 0.4, and the impact criteria a weight of 0.6. Once we'd assessed the importance and impact of each story, we lined them up based on the weighted score they recieved from this analysis. After that analysis, we scanned through the list and looked for anything that seemed out of place, especially something that was prioritized lower than waht seemed reasonable. In those cases, we asked "Which items would be willing to cut to cover this story?", and we moved it ahead of all of them. That exercise gave us a team-wide rank. At this point, we estimated the stories as a team using planning poker. I'll have to post something about that. It was suprisingly valuable.

This is where we really moved away from what an agile software development team would do. We broke the backlog out into a backlog for each individual writer. (That was a tough decision, and I hope we don't regret it. I'll try to write another post about that decision, but this is about how we prioritized our backlog.) Each writer is now looking at his individual backlog and trying to make sure that the top of the backlog is made up not only of stories that are most important, but that are ready to work on. In many cases, an item that we prioritized high in the stack may not be ready for several months. For example, the software may not be ready, or it may be the wrong time to work with the product unit to get the information that we'll need.

So, each writer moved things around to make sure the top of his stack reprents the most important items that are ready to start. We maintained the original team ranks in a separate field, though. That will allow us to evaluate whether there are writers who are working significantly lower in the team's priorities than most of the other writers. In those cases, we'll consider having him pick up something more important in another area.

That's how we prioritized our backlog. I'm curious how others prioritize content work. Let me know.

• Added information to the section (now called Configuring Your Build System) so that it now helps you understand what options you have (Understanding a Team Foundaiton Build System).
• Replaced the list of How-to's with an outline of everything you need to do.
• Finished with a link to what you're most likely to want to do next: Build the Application.

Now, we plan our work around these development tasks. Each is a work item in Team Foundation that we call a story. The stories are the items in our backlog that we prioritize, estimate, track and report our progress against. For example, one story in our backlog is "Create an application that subscribes to Team Foundation events". When that one is popped off the top of the stack and written, the content won't just cover the relevant APIs, but it will tie them together from beginning to end, with the information that you need to be successful in that task.

We have some guidelines that help us make sure our stories effectively meet our planning needs. The most important of these, I think, are:

• Describes what the developer (or project manager, administrator, etc) does, not what the product does.
• Has a start, finish, and outcome.
• Has a title that is clear to our team, management, the product team, and our customers

By taking the time to define our stories well, we have defined some content that will be more valuable than topics that just cover features. But, as with all things, we don't have time to do everything. So the next thing that we did is estimate and priotize the work so that we do the most important things first. I'll post something about that soon.

• Planning the Sprint
• Tracking Work Items
• Reporting Status

and the other in 2009.

• How we Track Content Work
• Managing Technical Reviews in TFS and SharePoint
• Reporting Progress

Well, it's an odd year. That means the pink salmon will be running this summer, and it's a good time to take a fresh look at how we're managing our content projects.

There are some important factors that have changed in the last couple of years. One is that we have adapted proven agile practices to build a proper backlog of content work. We create backlog items that meet our criteria for a good content requirement, we estimate them collaboratively using planning poker, and we rank them systematically, employing Mike Cohn's method of Theme Scoring. I'll post more about how and why we did this over the next few weeks.

Here's what I have so far:

• It's About What the User Does, not What the Product Does
• How do You Prioritize Content Work? Here's What We Did

You can drop the schema files in Program Files\Microsoft Visual Studio 10.0\Xml\Schemas and Visual Studio will validate your work item types or process template files using the appropriate schema. For example, if you are adding a field to a work iteim type, Visual Studio helps you by giving you the choice of valid properties and child elements.

Properties	Child Elements

With the schemas, Visual Studio also lets you know if you haven't specified all the required properties by using the squiggely underline under the element name.

And it checks for valid strings, too. For example, the refname in the following example uses a dash, which isn't valid.

Without the schema files, Visual Studio can only verify that you have well-formed XML, and you wouldn't get any of these helpful hints.

In some cases, the process tempalte files don't reference the schema files. You can work around this by opening the process template file you want to edit, and then selecting the appropriate tempalte file in the properties dialog.

In the cases described here, though, you’ll have to do some work if you want to use the new features in team projects that were upgraded from an earlier version of Visual Studio Team System.  You can enable these features immediately after upgrading your server, or you can begin using your team project and enable any or all of them at a more convenient time in the future.

The following posts provide manual steps for enabling each of these features. Hakan Eskici has also provided a script that you may find helpful, especially if you are using MSF for Agile Software Development v4.2 without customizations. Even if you've customized your process, you should be able to tweak the script and use it.

Enable Test Management: Visual Studio Team System 2010 includes features that allow you to manage your tests more effectively.  The screenshots below show the new test case, and the integration of the test steps with a bug. Read Chris Patterson’s blog post to learn how to add test management to team projects that you upgraded to Visual Studio Team System 2010.

Enable the Agile Planning Workbooks: You can use the new planning workbooks that are included in MSF for Agile Software Development v5.0 to help you plan your project and iterations. If your team project uses MSF for Agile Software Development v4.2, read Aaron Bjork’s blog posts to enable the iteration backlog and product backlog new workbooks.

Enable Agile or CMMI Dashboards and Reports: You can use the Team Foundation Power Tool to create a new portal for your team project based on one of the process templates in VS 2010.

• tfpt addprojectportal

You can also use tfpt.exe to create (or overwrite) the reports for your team project, based on the process templates.

• tfpt addprojectreports

Since the new portal and reports are based on the new process template that you used, you may have to customize them to work with your team project.

Enable Existing Reports: If you open your team project's Reports folder, you'll find that the reports you had been using aren't there. They are still available at https://<server>/reports/<team project>, but they will need to be updated to adapt to the changes to the schema of the cube and the warehouse database. These reports will continue to show the data as it existed before your server was upgraded. Aaron Bjork has a post that explains where the reports can be found and how to move them to the appropriate location on the report server. John Socha-Leialoha has posted information to help you make the changes to your reports so that they work with the new schema and pick up the new data from the upgraded server.

• Throw out what was there because it wasn't working
• Deliver a new set of SDK content that covers at least the core elements of the client object model.
• Add to that based on feedback
• Leverage good blog posts and other content in the community

Since then, we've fleshed out the coverage of the client object model, added the server object model, and we're about to publish content that covers the build process object model. Well, "covers" is probably an over-statement. The APIs are all listed, and we've added descriptions where we've had time to. We'll continue to add more descriptions and samples based on what we see you using, and the feedback that you provide in this blog. (We were not planning to cover the build process object model until we heard in this blog that you need that).

Although we haven't recieved a lot of ratings, if you believe the numbers that we have, this new approach seems to be working. The ratings for the SDK content are about on par with other content for Team Foundation. Given where we were at the beginning of the year, that's a big improvement.

What's missing now? Some things are obvious - we need more descriptions and samples in the most highly read reference topics. I'll look at page views to determine what to do first. Also, when you leave a comment on a specific page, either through the feedback control or as "community content" comment, I'll put those at the top of the backlog. So far, I've been able to handle all of those the same cycle that we receive them.

These are all toward the top of the table of contents, which suggests that viewers are coming in to the content through the table of contents. MSF for Agile is a notable expection. It's a child of Planning and Tracking Projects, but has more page views than any other topic except the top topic in the TOC for VS ALM. If the most viewed appeared larger in the TOC, the outline of these topics would look something like this.

 Visual Studio Application Lifecycle Management

What's new in Application Lifecycle Management for Visual Studio 2010   

MSF for Agile Software Development v5.0

Planning and Tracking Projects

Testing the Application

Allen

Extending Visual Studio Application Lifecycle Management 

You can customize some aspects of Visual Studio to extend existing features or to add new capabilities if you have special requirements. For example, you might define new test conditions for database unit tests if the test conditions provided with Visual Studio Premium or Visual Studio Ultimate are not sufficient to address your requirements.

Some of the extensibility points are provided with your Visual Studio installation. For other extensibility points, you must also install the Visual Studio SDK. You can identify the specific requirements for each extensibility point in the content that supports that extensibility point.

Team Foundation

• Extending Team Foundation
  • Connect to Team Foundation Server from a Console Application
  • Extending Work Item Tracking by Using the Client Object Model for Team Foundation
  • Extending Version Control
  • Events
  • Warehouse and Reports
• Client Object Model Reference
• Server Object Model Reference

IntelliTrace

• API Reference for IntelliTrace Extensibility

Database features

• Extending the Database Features of Visual Studio
  • Create Custom Database Refactoring Types or Targets
  • Create and Register Additional Rules for Analyzing Database Code
  • Generate Specialized Test Data with a Custom Data Generator
  • Define Custom Conditions for Database Unit Tests
  • Customize Database Build and Deployment by Using Build and Deployment Contributors
  • Create Custom Features for Database Projects
  • How to: Register and Manage Feature Extensions
  • How to: Distribute Custom Feature Extensions to Team Members
• Troubleshooting Feature Extensions
• API Reference for Database Features of Visual Studio

Testing

• Creating and Using Custom Plug-ins for Load and Web Performance Tests
  • How to: Use the Load test API
  • How to: Create a Load Test Plug-in
  • How to: Use the Web Performance Test API
  • How to: Create a Web Performance Test Plug-In
  • How to: Create a Request-level Plug-in
  • How to: Create a Web Service Test
  • How to: Create a Recorder Plug-in
  • How to: Create a Custom HTTP Body Editor for the Web Performance Test Editor
  • How to: Create a Visual Studio Add-in for the Web Performance Test Results Viewer
• API Reference for Testing Tools for Visual Studio ALM