If you have just installed Microsoft Team Foundation Server (TFS) 2012 and seem to be missing some of the new Web Access features this post is for you. These features need to be enabled post-install. Missing features include the ability to manage your backlog, plan your sprints, and define your team’s capacity. The figure below shows Team Web Access without these features.


Figure 1: Team Web Access is missing the sprint and backlog management features by default

You need to enable these features using the TFS Administration pages. To get started, open a browser and navigate to the server (you will need admin rights). You can go to the URL for the site as in [http://yourDomain:8080/tfs]. From here, you will want to select the link, “Administer Team Foundation Server”. Figure 2 below shows an example.


Figure 2: Use the TFS 2012 admin pages to get started

Clicking the link, Administer Team Foundation Server, will take you to the Control Panel for the server. Here you will see multiple tabs. You will want to select the “web access” tab. Figure 3 shows an example of the Control Panel page.


Figure 3: The Control Panel web page allows you to manage features of your TFS server

The web access tab allows you to control the features that are deployed by default for the given project collection. Notice in Figure 4 you have three options: Limited, Standard, and Full. Be default, Standard is set. To enable the full set of features that include sprint planning you select the Full link from the left side of the page. You then select the “Set as default web access” link as highlighted in Figure 4.


Figure 4: Select “Full” and then, “Set as default web access”

These features are now enabled on your site. If you return to your project site and refresh the page you should see them. Figure 5 shows an example. Notice the Sprint planning is now enabled.


Figure 5: Refresh your project site to see the new features including Sprint planning

The Microsoft Visual Studio Scrum 1.0 Template

Picking between the two Scrum-like templates in Visual Studio 2010 often comes down to culture. The Scrum template tends to be used by those that are fully bought into the Scrum programming lifestyle. It adapts well to self-organizing teams of peers that don’t make their commitments lightly, but once they do, they find a way to deliver real business value each sprint. These teams are motivated and experienced. They want to cut out the chatter that does not add direct value to the end product.

This chatter is often the data that higher-level managers want to collect to keep their eye on the development process that they just can’t seem to get their head around. A lot of this data is absent in the Scrum template. There are no production planning and sprint planning workbooks where resource allocation, planning, and tracking get done. Instead, the team works against a well-managed backlog (the Product Backlog query in TFS). The backlog is made up of Product Backlog Item work items. Each item is given a priority, business value, and an effort (similar to story points in a User Story in the Agile template).

Tasks are also managed differently. Unlike the Agile template that tracks estimated, remaining, and actual; the Scrum template task looks only at remaining work for a task. There is no place for the developer to put their actual hours on a task. This would just be more chatter to the team. They are concerned with the amount of work the sprint started with versus the remaining work on any given day. They can use that to track their velocity and completeness (the burndown report in the TFS template).

The reporting in the Scrum template is also considerably thinner; just burn down, build, and test reports. There are no sophisticated reports for double-checking the team’s productivity; their estimating prowess; their unplanned work—things are either done or not. A Scrum team culture typically does not see value in tracking each task by the estimated hour versus the actual hour. They know they are committed to delivering the work for the sprint and they will organize accordingly to do so.

Scrum culture prefer task sign-up to task assignment. This ensures the most important items (determined by priority and business value) are done first, people can work at their own pace, and are self-directed in the work they chose. Therefore, you will not see the resource allocation and planning workbooks in the Scrum template as you do in the Agile template. In fact, the lighter planning, tracking, and reporting aspects of the Scrum template can be seen as a direct reflection on the fact that Scrum teams are structured differently. They are a true team of peers that elect a Scrum master (and not a project manager in disguise) to facilitate and add value to the product. This role is not to double-check and lord over the team. Instead, they keep things moving smoothly and make everyone more productive. They are not a snitch to management; the Scrum process is meant to be transparent and open-book—no hiding and no need for police.

The Microsoft Solutions Framework (MSF) Agile 5.0 Template

The Agile template will be more comfortable to organizations that want to adopt Scrum-like practices but still desire a high-level of oversight, tracking, and reporting. In fact, we have seen that traditional project managers just moving to Scrum are more at-home with the Agile template. This has a lot to do with the planning and tracking aspects that are built into the workbooks (Product Backlog and Sprint Backlog), the work items themselves, and the reports.

The Agile template lets a project manager keep control of the project plan. They can assign tasks to resources; level the resources for a sprint; and track task estimates vs. actuals to determine how well the team is at executing work and doing estimation. They can even bring their sprint backlog into Project and assign traditional dependencies on tasks to chart out at what time in the sprint a given task might complete. Again, this would all fall contrary to the self-organized team in a Scrum culture. However, this type of work is highly engrained in modern project management and therefore built into the template.

There is considerably greater reporting and metrics capture in the Agile template. Managers can see tasks, tests, and bugs all rolling up to a user story. They can check unplanned work (work added to the sprint after the sprint started), bug trends, reactivations rates, and more. The management aspects of this template are geared toward the culture that wants to keep a close eye on their development team and measure their production process and not just their results.

A Side-by-Side Comparison


Scrum Template

Agile Template

Planning and tracking

All planning is done through the product backlog itself in TFS. Work items (tasks, tests, bugs, etc.) can be associated to product backlog items. Backlog items are assigned sprints.

Users self-select their tasks. Tracking is done based on effort and remaining effort.

Planning is done using the Product Planning and Iteration Backlog Excel workbooks. User stories make up the backlog. Work items (tasks, test cases, etc.) can be associated with user stories.

Users are assigned tasks and resources are leveled. Project managers can add dependencies to tasks in Project

Tasks are tracked for estimate, remaining, and actual.

Work items

Product backlog items make up the product backlog. Tasks and tests are associated to a product backlog item. Bugs are created and tracked.

There is also a Sprint work item that defines the start and end of the sprint. It also tracks the sprint retrospective.

User stories make up the product backlog. Tasks are used to implement a user story. Tests are defined to test a user story. Bugs are created and tracked accordingly.


Reporting is held to a minimum and includes the burn down, testing, and build reports.

These reports are intentionally focused on only the data that should concern the team. The real reporting is the software: either its done or not.

Includes a lot of sophisticated reports for tracking bugs, unplanned work, testing, progress, and team productivity.


Aligns closely with professional, experienced teams fully bought into Scrum. Holds true to the aspects of Scrum without adding additional weight or chatter.

Great for teams looking for both some Scrum-like benefits while holding onto the traditional oversight of the team while they work.

The ASP.NET MVC 3 default template includes an AccountController class, an AccountModels class, and a set of views in the Account folder. Together, these items allow for managing ASP.NET security including register, logon, and change password. Absent from the template, however, is an good method or example of how to use the returnUrl parameter that exists inside the Logon method of the Account controller:

public ActionResult LogOn(LogOnModel model, string returnUrl)

You can pass a URL (or route) to the parameter and the Logon method will do its job, returning the user to the page once the user has completed the logon. However, if you examine the default view generated for LogOn you will notice no mention or use of this parameter. Instead, just a standard Html.BeginForm() call.

A common scenario is to pickup the page that sent the user to the LogOn view and then route the user back to that page once they have completed a successful logon. You can do so with a few simple (and very effective) lines of code.

First, declare a string variable at the top of the LogOn view. Set this variable’s value to the Request object’s UrlReferrer.PathAndQuery property.  Make sure you check this value for null first as it would not be set in the case a user goes directly to the Logon page. The following code is an example (using the Razor syntax):

@model MvcApplication2.Models.LogOnModel



    ViewBag.Title = "Log On";


    string retUrl = "";

    if (ViewContext.HttpContext.Request.UrlReferrer != null)


      retUrl =



The only other step is to modify the BeginForm call on the same view page. Here you make sure to pass the string variable that is set the the referring URL. The following code shows an example:

@using (Html.BeginForm("Logon", "Account",
  new { model = this.Model, returnUrl = retUrl }))

That’s it! The LogOn action method in the AccountController class takes care of the actual redirect.

Hope this is useful to everyone.

I am writing some code using the new Entity Framework 4.1 code first model (where you simple objects to represent your database). I am using the System.ComponentModel.DataAnnotations to set rules such as required fields, validation with regular expressions, range validation, etc.

However, I could not find how you would implement the custom, “On[Property]Changing” patterns that is common in prior editions (using partial classes and partial methods). After a lot of looking, I stumbled upon the answer.

You use the new CustomValidation attribute. You can mark your property with this attribute as follows:

[CustomValidation(typeof(RegValidation), "ValidateAcceptTerms")]

public bool AcceptTerms { get; set; }


In this case, you are indicating that the validation code sits in the class, RegValidation inside the method, ValidateAcceptTerms.


You can then code this validation class as follows:

public class RegValidation


  public static ValidationResult ValidateAcceptTerms(bool isAccept)


    if (isAccept)


      return ValidationResult.Success;




      return new ValidationResult(

          "You must accept the terms of service in order to continue.");





You return an instance of ValidationResult (either success or with an error message) to indicate the results. In this way, you can implement custom validation on your EF 4.1 code first properties.

Note: since your objects are just simple objects, you can also write the logic in your setter and raise a validation exception. This will prevent the object from saving. However, it will not automatically get your validation error into the view. The CustomValidation attribute will.

Join me for an ALM Roundtable event in your area this fall. We will be in Reston, VA; Malvern, PA (outside of Philadelphia); and Pittsburgh, PA. All events are at a Microsoft office. Dates are as follows:

  • Reston, VA – October 13th
  • Malvern, PA – November 9th
  • Pittsburgh, PA – November 11th

I plan to first cover the full suite of tools available in Visual Studio 2010 from a role perspective (Project Manager, Requirements Analyst, Architect, Developer, Tester, Build Manager). In the afternoon, I will do a session title, The Full Testing Experience. Here we will cover automated and manual testing with Visual Studio and Test Professional 2010.

Click a link below to register and to get additional information.

An ALM Roundtable
The Full Testing Experience